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Abstract 


Commerce  transactions  are  being  increasingly  conducted  in  cyberspace.  We  not  only  browse 
through  on-line  catalogs  of  products,  but  also  shop,  bank,  and  hold  auctions  on-line. 

The  general  goal  of  this  research  is  to  answer  questions  such  as:  What  electronic  commerce  pro¬ 
tocols  try  to  achieve?  What  they  must  achieve?  And  how  they  achieve  it?  My  thesis  in  this 
dissertation  is  that  1)  In  electronic  commerce  transactions  where  participants  have  different  inter¬ 
ests  to  preserve,  protection  of  individual  interests  is  a  concern  of  the  participants,  and  should  be 
guaranteed  by  the  protocols;  and  2)  A  protocol  should  protect  a  participant’s  interests  whenever 
the  participant  behaves  according  to  the  protocol  and  trusted  parties  behave  as  trusted. 

In  this  dissertation,  we  propose  a  formal  definition  of  protection  of  individual  interests  and  a  frame¬ 
work  in  which  protocols  can  be  analyzed  with  respect  to  this  property.  Our  definition  is  abstract 
and  general,  and  can  be  instantiated  to  a  wide  range  of  electronic  commerce  protocols.  In  our 
framework,  we  model  electronic  commerce  systems  as  state  machines,  make  trust  assumptions  part 
of  protocol  specifications,  and  distinguish  executions  by  deviation  modes. 

We  specify  and  analyze  three  protocols  using  this  framework.  Our  analysis  uses  standard  mathe¬ 
matical  techniques.  We  found  protocol  weaknesses  that  have  not  been  found  before. 
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Chapter  1 

Introduction 


1.1  Context  and  Motivation 

Commerce  transactions  are  being  increasingly  conducted  in  cyberspace.  We  not  only  browse 
through  on-line  catalogs  of  products,  but  also  shop,  bank,  and  hold  auctions  on-line. 

For  electronic  commerce  to  sustain  its  current  growth  rate,  and  prevail  as  a  definitive  alternative 
to  traditional  physical  commerce,  nothing  should  happen  to  undermine  consumers’  confidence  in 
the  new  technology.  Thus,  both  electronic  transactions  and  entities  should  satisfy  a  minimal  set  of 
properties,  expected  by  users  of  electronic  commerce  systems.  For  instance,  in  an  electronic  sale 
transaction,  a  customer  should  receive  the  goods  which  he  or  she  pays  for,  and  a  merchant  should 
be  paid  for  goods  delivered.  Similarly,  electronic  cash  should  always  be  exchangeable  for  goods  and 
services.  Note  that  since  the  electronic  world  has  characteristics  of  its  own,  these  properties  may 
or  may  not  have  a  correspondence  in  the  physical  world. 

These  requirements  can  be  hard  to  meet.  First,  some  intrinsic  constraints  of  the  physical  world 
are  absent  in  the  electronic  world.  For  instance,  due  to  the  resources  and  knowledge  it  takes  to 
counterfeit  cash,  spurious  bills  and  coins  are  less  common  in  the  physical  world  than  they  would 
be.  In  the  electronic  setting,  however,  where  copying  data  items  is  cheap,  fast,  and  easy  to  disguise, 
spurious  currency  will  likely  to  be  much  more  common. 

Second,  participants  of  electronic  commerce  transactions  are  often  geographically  distributed, 
and  informal  mechanisms  that  require  face-to-face  interactions  and  that  can  help  bring  transac¬ 
tions  to  successful  completion  are  now  unavailable.  For  example,  customers  can  no  longer  judge 
merchants  by  their  storefronts,  and  different  parties  of  a  transaction  can  no  longer  easily  moni¬ 
tor  each  other  and  enforce  fulfillment  of  individual  obligations  in  the  transaction.  Some  types  of 
transactions  are  more  vulnerable  than  others.  For  example,  in  the  physical  world,  a  customer  does 
not  pay  with  cash  unless  he  or  she  is  given  goods  or  receipts  on  the  spot.  But  electronic  cash 
protocols  have  users  send  electronic  cash  over  networks.  This  capability  prompts  hard-to-settle 
disputes,  such  as  a  merchant  and  a  customer  disagreeing  over  whether  or  not  the  electronic  cash 
was  sent.  Was  the  cash  not  sent  by  the  customer?  Or  was  it  actually  received  by  a  lying  merchant? 
Problems  with  the  network  bring  in  other  possibilities:  the  cash  might  have  been  lost  during  the 
transmission,  due  to  a  network  failure. 

Third,  unlike  certain  other  classes  of  protocols  (e.g.,  key  distribution),  where  participants  share  a 
common  goal  (e.g.,  obtaining  a  secret  key  for  a  secure  communication)  [32,  71,  74],  here  participants 
typically  have  separate  and  often  conflicting  goals  in  mind  [42,  28,  89].  For  instance,  while  honest 
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customers  will  try  to  pay  for  goods  received,  dishonest  ones  may  cheat  and  try  to  obtain  goods  for 
free.  Similarly,  while  conscientious  merchants  will  strive  for  customer  satisfaction,  unscrupulous 
ones  may  not  care  if  goods  are  not  delivered,  or  may  deliver  something  else.  In  cyberspace,  where 
one  is  likely  to  interact  with  complete  strangers,  the  threat  of  cheating  is  real. 

To  achieve  properties  they  are  expected  to  satisfy,  electronic  commerce  protocols  rely  on  cryp¬ 
tography,  trusted  parties,  and  tamper-resistant  hardware.  These  protocols  are  usually  filled  with 
details  whose  purposes  are  not  immediately  clear.  To  make  matters  even  worse,  critical  assump¬ 
tions  are  often  left  implicit  in  their  specifications.  Given  this  scenario,  it  is  not  always  clear  what 
these  protocols  try  to  achieve,  what  they  must  achieve,  and  how  they  achieve  it. 

This  research  addresses  these  questions,  and  focuses  on  a  requirement  called  protection  of  indi¬ 
viduals  ’  interests. 

The  rest  of  this  chapter  is  structured  as  follows.  In  Section  1.2,  we  introduce  the  notion 
of  protection  of  individuals’  interests  starting  from  the  notion  of  fairness.  In  Section  1.3,  we 
introduce  the  notion  of  trust  assumptions,  and  discuss  their  importance  in  protocol  design,  analysis, 
implementation,  and  deployment.  In  Section  1.4,  we  give  an  overview  of  this  thesis  work.  In 
Section  1.5,  we  summarize  our  contributions.  Section  1.6  presents  related  work,  and  Section  1.7 
gives  a  roadmap  for  the  rest  of  this  dissertation. 

1.2  Protection  of  Individuals’  Interests 

The  notion  of  protection  of  individuals’  interests  is  a  generalization  of  the  notion  of  fairness.  In 
this  section,  we  give  an  intuition  about  the  former  starting  from  a  common  interpretation  of  the 
latter. 

The  notion  of  fairness  first  appeared  in  the  context  of  protocols  for  exchange  of  secrets,  contract 
signing,  and  certified  electronic  mail  [10,  11,  7,  27,  38,  65,  85,  75,  83,  88].  More  recently,  fairness 
has  also  been  studied  in  the  context  of  protocols  for  exchange  of  documents,  electronic  sale,  and 
non-repudiation  [6,  5,  20,  28,  31,  53,  57,  58,  89,  90]. 

The  most  widely  used  intuitive  interpretation  of  fairness  says  that  a  protocol  is  fair  if  no  protocol 
participant  can  gain  any  advantage  over  other  participants  by  misbehaving.  Gaining  advantage 
means  different  things  in  different  contexts.  For  example,  in  a  sale  transaction,  a  customer  gains 
advantage  if  she  receives  the  goods,  but  the  merchant  does  not  receive  the  payment;  and  a  merchant 
gains  advantage  if  he  receives  the  payment,  but  the  customer  does  not  receive  the  goods.  In  certified 
electronic  mail,  the  recipient  of  a  message  gains  advantage  if  the  sender  does  not  receive  the  proof 
of  delivery;  similarly,  the  sender  gains  advantage  if  she  has  a  proof  of  delivery,  even  though  the 
recipient  did  not  receive  the  message. 

The  usual  notion  of  fairness,  however,  is  not  subtle  enough.  In  particular,  one  party’s  interests 
can  be  compromised  even  if  no  one  else  has  gained  any  advantage.  This  situation  can  happen,  for 
example,  in  sale  transactions  where  customers  pay  by  electronic  cash.  If  the  payment  sent  by  the 
customer  gets  lost  while  in  transit,  and  never  reaches  the  merchant,  and  the  merchant  does  not  send 
the  goods,  then  we  are  in  a  scenario  where  neither  the  customer  nor  the  merchant  receives  their 
shares  in  the  exchange,  even  though  the  customer  has  effectively  lost  money.  Under  this  scenario, 
no  one  has  gained  any  advantage,  but  the  customer’s  interests  have  certainly  been  hurt:  she  did 
not  receive  anything  in  return  for  the  money  she  has  now  lost.  Users  of  ecommerce  protocols  need 
to  be  protected  against  such  losses. 

To  handle  this  and  other  examples,  we  introduce  a  new  property  called  protection  of  individuals’ 
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interests ,  which  is  centered  on  the  notion  of  protection  of  different  participants  interests  in  a 
transaction.  Intuitively,  a  protocol  protects  a  participant’s  interests  if  his  or  her  interests  cannot 
he  hurt  even  if  everybody  else  misbehaves. 

Protection  of  individuals’  interests  generalizes  fairness  in  two  ways.  First,  it  has  a  wider  domain 
of  applicability:  while  fairness  is  applicable  only  in  transactions  where  the  zero-sum  rule  holds, 
protection  of  individuals’  interests  is  applicable  in  any  transaction  where  participants  have  different 
interests  to  preserve.  In  addition  to  exchange  protocols,  which  are  the  only  ones  that  have  been 
studied  with  respect  to  fairness,  we  can  now  examine  an  assortment  of  other  types  of  protocols 
with  respect  to  protection  of  individuals’  interests.  Payment  protocols,  withdrawal  protocols,  and 
auction  protocols  are  some  examples.  In  payment  protocols,  the  payer’s  interest  is  protected  if  the 
money  she  gives  up  is  actually  received  by  the  payee;  and  the  payee’s  interest  is  protected  if  what 
he  receives  is  worth  real  money.  In  withdrawal  protocols,  the  withdrawer’s  interest  is  protected 
if  the  amount  deducted  from  her  account  is  never  bigger  than  the  amount  of  cash  she  receives; 
the  bank’s  interest  is  protected  if  the  withdrawer  cannot  obtain  cash  without  having  her  account 
deducted.  Finally,  in  auction  protocols,  the  auctioneer’s  interest  is  protected  if  she  always  sells 
her  goods  at  the  highest  price  bidders  are  willing  to  pay;  and  a  bidder’s  interest  is  protected  if  he 
is  sold  the  auctioned  goods  if  his  offer  is  the  winning  bid,-  and  the  sale  price  was  not  artificially 
inflated  by  bidding  frauds. 

Second,  protection  of  individuals’  interests  assumes  a  less  restricted  failure  model.  To  analyze 
a  protocol  with  respect  to  fairness,  one  considers  scenarios  where  a  participant  misbehaves,  and 
checks  whether  the  participant  himself  can  obtain  any  advantage  [3,  42].  To  analyze  a  protocol 
with  respect  to  protection  of  individuals’  interests,  one  considers  scenarios  where  everything  (other 
participants  and  the  network)  except  the  participant’s  local  execution  can  go  wrong,  and  checks 
whether  the  same  participant’s  interests  can  be  hurt.  This  second  failure  model  takes  into  account 
threats  that  are  not  considered  when  one  is  concerned  with  fairness.  They  include  sabotage  attacks 
where  a  participant  misbehaves  not  to  obtain  advantages  for  herself,  but  to  hurt  someone  else’s 
interests.  (These  attacks  can  sometimes  hurt  the  interests  of  even  the  perpetrator  herself.)  They 
also  include  system  failures  that  are  out  of  control  of  the  participants  themselves.  Network  failures 
are  an  example.  Finally,  they  include  collusions  among  multiple  participants.  This  failure  model, 
in  essence,  assumes  that  one  should  not  rely  on  anyone  other  than  oneself  or  anything  other  than 
the  protocol  to  protect  one’s  own  interests. 

This  assumption  can  be  too  stringent  however.  When  a  designer  uses  trusted  parties  in  a 
protocol,  protection  of  the  various  individuals’  interests  typically  rely  on  certain  parties  behaving 
as  trusted.  We  will  discuss  trusted  parties  and  their  roles  in  protection  of  individuals’  interests  in 
the  next  section. 


1.3  Trusted  Parties  and  Trust  Assumptions 

Executions  of  security  and  electronic  commerce  protocols  are  subject  to  potential  disruptions  by 
third  party  intruders/participants  of  a  protocol  themselves.  These  disruptions  can  lead  to  inad¬ 
missible  outcomes,  where  basic  properties  of  a  transaction  are  violated.  For  example,  a  disrupted 
execution  of  an  authentication  protocol  may  wrongly  authenticate  a  party  A  as  a  different  party 
B. 

One  way  of  preventing  corruption  of  outcomes  is  to  use  trusted  parties.  In  a  protocol,  trusted 
parties  are  parties  entrusted  with  correctly  and  reliably  carrying  out  protocol  steps  that  are  decisive 
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to  guaranteeing  satisfaction  of  a  targeted  property.  For  example,  trusted  parties  are  entrusted  with 
generating  fresh  keys  in  authentication  protocols  to  guarantee  authentication  [71,  74,  81].  In  some 
payment  protocols  [84],  they  are  entrusted  with  implementing  transaction  processing  [66]  to  achieve 
fairness.  This  notion  of  trust  is  a  refinement  of  the  definition  of  trust  adopted  by  the  US  Department 
of  Defense  in  the  context  of  secure  systems,  which  states  that  “a  trusted  component  is  one  which,  if 
it  breaks,  can  compromise  system  security”  [1],  It  is  a  refinement  because  it  distinguishes  “breaks” 
that  matter  and  those  that  do  not.  For  a  concrete  example,  see  Example  1.1  below. 

A  trusted  party  can  be  one  of  the  main  parties  involved  in  a  protocol  (for  instance,  banks  in 
ecash  protocols  are  usually  trusted)  or  someone  called  in  solely  to  mediate  a  transaction  (like  T  in 
Example  1.1). 

Trusted  parties  are  entrusted  with  correctly  and  reliably  carrying  out  critical  steps  of  a  proto¬ 
col.  In  the  context  of  protocol  design  and  analysis,  entrustment  simply  translates  into  assumptions. 
These  assumptions  -  about  how  trusted  parties  behave  -  are  commonly  called  trust  assumptions. 
When  reasoning  about  a  protocol,  one  effectively  assumes  that  ordinary  parties  can  deviate  arbi¬ 
trarily  from  the  protocol,  while  trusted  parties  can  deviate  so  long  as  they  do  not  violate  trust 
assumptions. 

To  be  concrete,  consider  the  following  hypothetical  fair  exchange  protocol, 

Example  1.1  A  mediated  exchange  protocol: 

1.  A-^T:a 

2.  B-^T:h 

3.  T  — ^  B  :  a 

4.  T  A  :  b 

through  which  A  and  B  trade  items  a  and  6,  under  fair  mediation  of  trusted  party  T.  A  is  prescribed 
to  release  a  and  wait  to  receive  b.  Since  he  is  an  ordinary  party,  we  make  no  assumption  about  how 
he  will  behave  in  an  actual  run  of  the  protocol.  For  example,  he  may  release  a,  and  decide  to  quit 
his  execution  before  receiving  b.  Or  he  may  withhold  a,  and  hope  to  receive  b  for  free.  The  same 
is  true  of  B.  T  is  prescribed  first  to  receive  a  and  6,  and  then  to  forward  them  to  their  respective 
destinations.  Since  T  is  a  trusted  party,  it  is  subject  to  two  trust  assumptions: 

Al:  T  will  not  forward  the  items  before  it  has  received  them  both;  and 
A 2:  If  T  forwards  any  item,  it  forwards  both. 

This  set  of  trust  assumptions  says  that  T  will  not  halt  its  local  execution  between  steps  3  and 
4  (this  would  violate  A2),  but  could  do  so  between  steps  2  and  3.  Note  that  X”s  stopping  between 
steps  3  and  4  makes  an  exchange  unfair,  while  its  stopping  between  steps  2  and  3  does  not.  Finally, 
this  protocol  implements  fair  exchange,  as  long  as  communication  channels  are  reliable  and  T  is  a 
trusted  party  that  satisfies  trust  assumptions  Al  and  A2.  Without  these  assumptions,  fairness  is 
not  guaranteed. 

Trust  assumptions  differ  from  other  system  assumptions.  System  assumptions  deal  with  general 
characteristics  of  a  system  (e.g.,  networks  can  go  down  or  processors  can  halt),  whereas  trust 
assumptions  specify  what  trusted  parties  are  trusted  to  do  in  the  context  of  a  protocol  execution. 
Thus,  while  system  assumptions  are  protocol-independent,  trust  assumptions  are  protocol-specific. 

The  knowledge  of  a  protocol’s  trust  assumptions  is  important  to  those  analyzing  the  design 
of  the  protocol.  Using  these  assumptions,  analysts  can  build  models  that  better  reflect  what  the 
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designers  had  in  mind,  making  the  analysis  more  meaningful.  The  knowledge  of  trust  assumptions 
is  also  important  to  implementers  and  deployers,  who  need  to  realize  these  assumptions  in  the  real 
system.  Knowing  these  assumptions  enables  them  to  determine  whether  a  protocol,  as  conceived 
by  its  designers,  is  realizable;  estimate  the  cost  of  realizing  it;  and  compare  different  protocols  of  a 
class  with  respect  to  their  reliance  on  trusted  parties  (typically,  the  less  trust  a  protocol  requires, 
the  less  vulnerable  is  the  protocol).  Finally,  the  knowledge  of  trust  assumptions  is  important  to 
prospective  users  of  a  protocol.  Knowing  the  trust  assumptions  allows  them  to  decide  whether  a 
prospective  participant  of  a  protocol  is  fit  to  be  a  trusted  party,  and  to  evaluate  the  risks  of  relying 
on  this  prospective  trusted  party. 

Even  though  knowledge  of  trust  assumptions  is  important  in  so  many  contexts,  they  have 
mostly  remained  in  the  back  of  the  designers’  minds,  and  have  rarely  been  made  explicit.  In 
this  dissertation,  we  propose  changing  this  state  of  practice:  we  introduce  a  framework  where 
trust  assumptions  are  made  explicit  as  part  of  a  protocol  specification.  Explicit  trust  assumptions 
are  then  used  in  modeling  and  analyzing  protocols.  We  explain  how  we  specify  and  use  trust 
assumptions  in  Section  1.4.2. 

1.4  Thesis  Overview 

Thesis  Statement:  Electronic  commerce  protocols  form  a  distinct  class  of  crypto¬ 
graphic  protocols  in  terms  of  what  it  means  for  a  protocol  to  be  correct.  Formal  methods 
can  help  not  only  in  formalization  of  correctness  conditions,  but  also  in  protocol  analysis. 

To  support  this  thesis,  we  identify  a  novel  property  called  protection  of  individuals’  interests  that 
all  electronic  commerce  protocols  should  satisfy.  We  then  propose  a  formal  definition  of  protection 
of  individuals’  interests  and  a  framework  in  which  protocols  can  be  analyzed  with  respect  to  this 
property.  Our  definition  is  abstract  and  general,  and  can  be  instantiated  to  concrete  protocols 
from  different  classes  of  electronic  commerce  protocols.  In  our  framework,  we  model  electronic 
commerce  systems  as  state  machines,  make  trust  assumptions  part  of  protocol  specifications,  and 
distinguish  executions  by  deviation  modes. 

Using  this  framework,  we  specify  and  analyze  three  protocols  [42,  28,  14].  Our  analysis  uses 
standard  mathematical  techniques. 

In  the  rest  of  this  section,  we  sketch  the  various  components  of  our  framework  and  our  definition 
of  protection  of  individuals’  interests. 

1.4.1  Modeling  Electronic  Commerce  Systems 

We  see  electronic  commerce  systems  abstractly  as  sets  of  interconnected  agents  where  each  agent 
runs  a  process.  Agents  have  private  local  stores  where  they  hold  their  data.  They  also  have 
the  capability  of  generating  new  data,  communicating  with  each  other  by  message  passing,  and 
deriving  new  data  from  existing  ones  using  cryptography.  Communication  channels  are  end-to-end, 
and  there  is  a  channel  connecting  any  pair  of  agents  in  a  system.  Both  the  communication  and 
process  executions  are  asynchronous. 

We  consider  both  process  failures  and  channel  failures.  Since  channel  failures  manifest  them¬ 
selves  in  the  processes,  however,  we  cast  them  all  in  terms  of  process  failures.  In  this  dissertation, 
processes  can  fail  in  two  ways:  they  can  failstop  or  they  can  deceive.  A  process  failstops  if  it 
terminates  abnormally,  in  a  way  not  prescribed  by  the  algorithm  it  is  running.  A  process  deceives 
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if  it  follows  the  algorithm  only  apparently:  at  each  step,  the  process  executes  the  type  of  action 
prescribed  by  the  algorithm,  but  possibly  with  bogus  messages. 

Both  failstopping  and  deception  are  simple  types  of  failures.  Yet  they  model  realistic  attacks 
to  electronic  commerce  systems.  Power  outages,  computer  crashes,  and  user-initiated  interruptions 
can  all  cause  premature  termination  of  a  process;  connection  failures  are  common  with  today’s 
Internet;  and  deceptions  can  be  easily  carried  out  by  malicious  users. 

We  assume  secure  communication  in  our  model:  if  a  message  is  received,  then  it  is  received 
by  the  intended  recipient,  authenticated,  confidential,  and  intact.  Effectively,  we  assume  that 
processes  use  the  service  provided  by  an  underlying  layer  of  cryptographic  protocols. 

The  characterization  of  electronic  commerce  systems  depicted  above  differs  from  the  ones  tradi¬ 
tionally  used  in  investigations  of  security  protocols.  In  traditional  characterizations,  participants  of 
a  protocol  always  behave  correctly,  and  there  is  invariably  an  intruder  that  can  eavesdrop  and  cor¬ 
rupt  communications  among  the  participants.  In  our  characterization,  participants  of  a  protocol, 
including  trusted  parties,  may  fail  or  misbehave,  but  communications  among  them  are  assumed 
to  be  secure.  Doing  so  allows  us  to  abstract  away  possible  spoofings,  sniffings,  and  tamperings 
of  messages  by  third  party  intruders,  which  makes  modeling  them  unnecessary.  The  goal  is  to 
focus  on  answering  the  core  question:  What  can  participants  of  a  transaction,  with  the  “help”  of 
unreliable  communication  channels,  do  to  violate  other  participants’  individual  interests? 

We  formalize  this  abstract  model  in  state  machines.  Our  formalization  is  standard. 

1.4.2  Specifying  and  Using  Trust  Assumptions 

Traditionally,  protocol  specifications  specify  protocol  principals,  initial  conditions,  and  protocol 
rules.  In  our  framework,  they  also  specify  trust  assumptions. 

Trust  assumptions  are  specified  in  linear-time  temporal  logic  [67].  Each  trusted  party  has 
associated  with  it  a  set  of  logic  expressions  specifying  its  trusted  behaviors.  For  example,  the 
specification  of  the  protocol  in  Example  1.1  (Section  1.3)  would  include  two  formulas  specifying 
A1  and  A 2. 

Given  that  trusted  parties  are  assumed  to  behave  as  trusted,  executions  of  trusted  parties  that 
violate  their  corresponding  trust  assumptions  should  not  appear  in  the  model  of  the  overall  system. 
In  our  framework,  trust  assumptions  are  used  to  filter  out  trust-violating  executions  from  the  set 
of  all  possible  executions  of  a  protocol.  We  explain  the  filtering  mechanism  in  the  next  subsection. 

1.4.3  Defining  Protection  of  Individuals’ Interests 

Ideally,  protocols  should  protect  the  interests  of  each  of  its  participants.  In  this  subsection,  we  define 
the  conditions  under  which  they  should  provide  such  protection.  To  do  so,  we  first  characterize 
different  types  of  executions  performed  by  parties  in  a  protocol. 

Definition  1.2  A  compliant  execution  is  one  in  which  the  party  behaves  as  prescribed  by  the 
protocol.  A  compliant  execution  runs  to  completion,  or  terminates  prematurely  because  of  remotely 
originated  communication  disruptions. 

Definition  1.3  A  deviant  execution  is  one  in  which  the  party  does  not  behave  as  prescribed  by 
the  protocol.  We  consider  two  types  of  deviant  executions.  An  abortive  execution  is  one  which 
terminates  prematurely  because  of  local  factors,  and  a  deceptive  execution  is  one  which  includes 
deceptive  steps  (Section  1.4.1). 


6 


Definition  1.4  A  trustworthy  execution  is  one  in  which  trust  assumptions  made  about  the  party 
are  satisfied. 

Note  that  the  types  of  executions  defined  above  do  not  conform  to  the  traditional  classification 
of  executions,  based  on  failure  modes.  The  traditional  classification  is  inadequate  here  for  two 
reasons.  First,  it  does  not  distinguish  between  failures  that  one  causes  to  one’s  own  execution  and 
those  caused  by  other  parties  of  the  protocol.  Second,  it  does  not  distinguish  between  behaviors 
that  obey  trust  assumptions  and  those  that  violate  them. 

We  now  give  the  primary  definition  of  this  subsection: 

Definition  1.5  Given  a  protocol  and  one  of  its  parties  p ,  the  protocol  protects  p’s  interests  (or, 
for  short,  is  p-protective )  if  p’s  interests  are  preserved  in  all  executions  where  p  executes  compli¬ 
antly  (p’s  execution  is  compliant),  and  all  trusted  parties  execute  as  trusted  (their  executions  are 
trustworthy) . 

Note  that  Def.  1.5  implicitly  asserts  three  important  policies.  First,  a  party  is  entitled  to 
protection  only  if  it  behaves  compliantly.  Second,  all  trusted  parties  are  relied  upon  to  behave 
as  trusted.  Third,  a  party  is  entitled  to  protection  even  when  other  parties  execute  deviantly. 
Depending  upon  assumptions  about  how  the  parties  of  a  protocol  can  deviate,  an  analysis  can 
focus  on  one  type  of  deviation  or  another. 

Def.  1.5  is  general  and  abstract  in  that  p’s  protection  property ,  which  describes  the  conditions 
under  which  p’s  interests  are  preserved  in  an  execution,  is  not  specified.  Protection  properties 
cannot  be  specified  without  reference  to  a  protocol,  because  they  vary  from  protocol  to  protocol. 
Individuals’  interests  in  an  auction  protocol  are  certainly  different  from  those  in  a  payment  protocol. 
There  are  variations  even  within  a  single  class  of  protocols.  For  example,  receiving  payment  may 
mean  receiving  cash  in  one  protocol  and  receiving  a  check  in  another,  and  this  difference  leads  to 
different  protection  properties. 

1.4.4  Case  Studies 

Using  the  framework  sketched  above,  we  specify  and  analyze  three  electronic  commerce  protocols: 
Franklin  and  Reiter’s  fair  exchange  protocol  with  a  semi-trusted  third  party  [42];  NetBill  (a  protocol 
for  purchasing  information  goods  on  the  Web,  proposed  by  Cox,  Sirbu,  and  Tygar)  [28];  and 
Brands’s  off-line  cash  with  observers  protocol  [14].  Each  case  study  includes  1)  a  description  of 
an  abstraction  of  the  protocol,  2)  a  formalization  of  the  abstract  protocol,  3)  a  specification  of 
protection  properties,  and  4)  protocol  analysis. 

During  the  formalization,  we  identify  and  specify  trust  assumptions  pertaining  to  the  trusted 
parties.  Because  trust  assumptions  are  not  given  explicitly  in  the  original  published  versions  of 
these  protocols,  we  had  to  infer  them  in  some  cases,  and  identify  them  afresh  in  others. 

Different  protocols  require  different  amounts  of  effort  in  specification  of  their  protection  prop¬ 
erties.  For  Franklin  and  Reiter’s  protocol,  we  simply  transcribe  the  corresponding  fair  exchange 
properties.  For  NetBill,  we  have  to  take  into  account  not  only  what  happens  on-line,  but  also 
dispute  resolutions  that  happen  off-line.  For  Brands’s  protocol,  protection  properties  had  to  be 
formulated  from  scratch. 

In  the  analysis,  we  consider  protection  properties  of  different  parties  in  turn.  Given  a  party 
p ,  we  analyze  /^protection  under  three  modes:  compliance,  abortion,  and  deception.  Within  each 
mode,  we  consider  two  types  of  scenarios:  one  with  reliable  communication  channels  and  the  other 
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with  unreliable  ones.  In  each  case,  we  show  whether  the  protocol  is  p- protective  and  what  would 
happen  if  trust  assumptions  are  violated.  We  also  suggest  fixes  whenever  appropriate. 

Note  that  the  protocols  we  analyze  were  not  necessarily  designed  to  function  under  all  the 
scenarios  we  consider.  (Their  designers  may  have  made  stronger  or  weaker  assumptions.)  We 
submit  them  to  analysis  under  all  our  scenarios,  nonetheless,  to  see  how  they  would  do  under 
different  conditions. 

1.5  Contributions 

This  dissertation  makes  several  contributions  to  the  fields  of  electronic  commerce,  computer  secu¬ 
rity,  and  formal  methods.  The  main  contributions  are  listed  below. 

•  We  include  trust  assumptions  as  an  explicit  part  of  protocol  specifications.  We  then  use 
them  to  formalize  executions  of  trusted  parties.  This  formalization  allows  us  to  model  semi¬ 
trustworthiness. 

Explicit  trust  assumptions  also  enable  comparisons  and  evaluations  of  protocols  with  respect 
to  their  trust  requirements.  They  are  also  an  invaluable  guide  to  implementers  and  deployers. 

•  We  identify  protection  of  individuals’  interests  as  a  requirement  for  electronic  commerce 
protocols,  and  formalize  the  conditions  under  which  protocols  should  provide  such  protection. 
The  formalization  uses  several  novel  types  of  executions:  compliant,  abortive,  deceptive,  and 
trustworthy. 

Our  formalization  is  abstract  and  general,  and  provides  a  unifying  framework  for  analyzing 
different  classes  of  protocols. 

•  We  analyze  three  protocols  using  our  model.  The  analyses  established  whether  the  protocols 
protect  the  interests  of  their  participants  under  different  scenarios. 

We  found  protocol  weaknesses  that  have  not  been  found  before,  and  suggest  possible  fixes  for 
the  weaknesses  we  found. 

1.6  Related  Work 

Formalization  and  analysis  of  cryptographic  and  security  protocols  have  been  topics  of  research  for 
over  twenty  years.  Authentication  and  key  exchange  protocols  have  by  far  been  the  most  stud¬ 
ied,  with  secrecy,  authentication,  and  integrity  being  the  properties  receiving  the  most  attention. 
Because  we  focus  on  protection  of  individuals’  interests,  and  assume  secrecy,  authentication,  and  in¬ 
tegrity  as  provided  by  underlying  services,  this  body  of  research  is  not  as  closely  related  to  our  work 
as  it  might  appear.  We  thus  omit  it  here,  and  point  interested  readers  elsewhere  for  surveys  [79] 
and  summaries  of  the  history  and  the  state-of-art  of  formal  cryptographic  protocol  analysis  [69]. 

In  what  follows,  we  discuss  three  different  categories  of  related  work,  pointing  out  major  differ¬ 
ences  that  distinguish  them  from  our  work. 

1.6.1  Atomicity,  Fairness,  and  Related  Properties 

Protection  of  individuals’  interests  is  a  generalization  of  fairness,  and  fairness  is  closely  related  to 
atomicity.  An  introduction  to  fairness  appears  in  Section  1.2;  we  do  not  repeat  it  here.  As  for 
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atomicity  [84],  there  are  three  levels  of  atomicity.  Money- atomic  protocols  transfer  funds  from  one 
party  to  another  without  creating  or  destroying  money.  Goods-atomic  protocols  are  money-atomic, 
and  guarantee  that  goods  are  delivered  if  and  only  if  money  is  transferred.  Finally,  certified  delivery 
protocols  are  goods-atomic,  and  allow  both  merchants  and  customers  to  prove,  to  a  third  party, 
which  goods  were  delivered. 

Atomicity  and  fairness  were  both  introduced  by  protocol  designers.  In  [84,  3, 42,  89],  an  informal 
definition  of  atomicity  (respectively  fairness)  is  presented,  a  protocol  or  a  class  of  related  protocols 
are  proposed,  and  the  protocols  are  shown  to  satisfy  the  property.  These  definitions  and  analyses 
are  informal  and  tailored  to  the  specifics  of  the  protocol.  Thus,  even  though  they  provide  good 
insights  and  intuitions  about  a  specific  protocol,  they  are  ad  hoc,  not  definitive,  and  cannot  be 
applied  straightforwardly  to  other  protocols. 

In  addition  to  analyses  conducted  by  the  designers  themselves,  there  exist  case  studies  focused 
on  atomicity  and  fairness,  conducted  independently  by  formal  methods  researchers  [51,  80,  78]. 
Heintze  et  al  [51]  specified  simplified  versions  of  NetBill  [28]  and  Digicash  [22]  in  CSP  [52],  and  ana¬ 
lyzed  them  with  respect  to  money-atomicity  and  goods-atomicity  using  the  FDR  model  checker  [64]. 
Shmatikov  and  Mitchell  [80]  specified  a  contract  signing  protocol  by  Asokan  et  al  [4],  and  analyzed 
it  with  respect  to  fairness  using  Mur0  [34].  Schneider  [78]  specified  Zhou  and  Gollman’s  non¬ 
repudiation  protocol  [89],  and  analyzed  it  using  CSP;  the  proofs  are  carried  out  by  hand. 

The  first  two  case  studies  share  a  number  of  characteristics.  Both  use  a  model  where  trusted 
parties  always  behave  according  to  the  protocol,  while  ordinary  parties  can  misbehave.  Both 
specify  atomicity  (respectively,  fairness)  as  a  global  property.  Neither  has  a  well-defined  failure 
model.  Neither  is  able  to  explain  satisfactorily  idiosyncrasies  that  arise  from  specifying  atomicity 
and  fairness  as  global  properties.  In  particular,  neither  formalizes  the  distinction  between  inter¬ 
esting  and  uninteresting  violations  of  the  properties.  (Uninteresting  violations  are  those  where  the 
misbehaving  parties  are  the  victims  themselves.) 

The  third  case  study,  in  contrast,  does  not  have  such  weaknesses.  Fairness  is  specified  as  an 
agent-centric  property,  just  as  our  protection  of  individuals’  interests  is  agent-centric.  Its  system 
model  closely  follows  ours,  except  for  its  treatment  of  trusted  parties:  they  always  behave  according 
to  the  protocol  [78].  Schneider  focuses  on  a  single  non-repudiation  protocol,  and  does  not  propose 
a  general  and  abstract  framework  that  is  applicable  for  a  wider  class  of  protocols. 

Other  case  studies  focus  on  credit  card  based  electronic  payment  protocols  [13,  70].  Bolig- 
nano  [13]  analyzed  C-SET  [33]  using  Coq  [35];  Meadows  and  Sy verson  [70]  discussed  and  formally 
specified  requirements  for  SET  [68]  in  a  version  of  the  NRL  Protocol  Analyzer  Temporal  Require¬ 
ments  Language  [82].  These  case  studies  differ  from  the  ones  discussed  above  in  that,  instead 
of  focusing  on  some  specific  properties,  they  address  all  requirements  that  seem  desirable  in  the 
context  of  their  protocols.  The  requirements  are  not  named,  but  are  loosely  separated  into  groups. 
There  are,  for  example,  customer  requirements,  merchant  requirements,  and  gateway  requirements. 
Some  requirements  within  these  three  groups  clearly  resemble  what  we  call  protection  properties. 

Also  in  these  studies,  different  hypotheses  about  how  different  parties  behave  are  made.  For 
each  hypothesis,  the  properties  that  should  hold  are  specified.  The  protocols  are  then  analyzed 
under  different  hypotheses  with  respect  to  their  corresponding  properties.  Some  example  scenarios 
are:  everyone  behaves  according  to  the  protocol;  everyone  except  the  customer  behaves;  no  one 
but  the  merchant  behaves;  and  so  forth.  The  intent  is  to  verify  what  conclusions  different  parties 
can  draw  under  different  circumstances. 

Despite  their  comprehensiveness,  these  case  studies  have  two  major  weaknesses.  First,  because 
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the  properties  are  not  named,  and  the  issues  they  involve  are  not  deeply  discussed,  it  is  not 
straightforward  to  identify  the  essence  of  these  properties,  which  makes  applying  their  approach 
to  other  protocols  difficult.  Second,  because  the  protocols  are  analyzed  with  respect  to  different 
properties  (sometimes  weaker  or  stronger  versions  of  a  property)  under  different  scenarios,  it  is  not 
immediately  clear  what  core  properties  the  protocols  satisfy. 

1.6.2  Other  Properties 

Other  aspects  of  electronic  commerce  protocols  have  also  been  studied.  Kailar  proposed  a  BAN-like 
logic  [19]  for  reasoning  about  accountability,  and  used  it  to  analyze  several  protocols  [54].  Kessler 
and  Neumann  [55]  extended  AUTOLOG  [56]  with  predicates  and  rules  to  model  accountability,  and 
proved  that  the  new  calculus  is  correct  with  respect  to  the  formal  semantics  given  in  [86].  They  then 
used  this  calculus  to  analyze  SET  [68]  and  Payword  [77].  Kindred  [59]  generated  automatic  checkers 
for  both  Kailar’s  logic  and  AUTOLOG  using  Revere.  He  then  applied  the  resulting  checkers  to  a 
variety  of  protocols.  Finally,  Clarke  et  al  [26]  proposed  a  logic  of  knowledge  for  specifying  security 
properties  of  electronic  commerce  protocols.  They  then  used  this  logic  to  specify  a  few  properties, 
such  as  privacy  and  anonymity,  for  the  1KP  protocol  [6]. 

1.6.3  Trust 

Also  related  to  this  dissertation  are  research  efforts  that  try  to  understand  and  formalize  the  notion 
of  trust.  Trust  has  long  been  studied  in  the  context  of  multi-domain  authentication  protocols  [9, 
44,  61,  81].  In  this  context,  trust  is  typically  distributed  among  a  number  of  key  or  name  servers, 
and  structured  in  some  pre-defined,  hierarchical  way.  To  accept  an  authentication,  a  user  needs  to 
trust  only  part  of  the  hierarchy. 

The  notion  of  trust  for  distributed  authentication  has  also  been  studied  independently  of  any 
protocol  or  name  scheme.  For  Yahalom  et  al  [87],  trust  is  a  relationship  between  two  parties,  and 
one  party  can  trust  another  in  any  respect.  Starting  from  these  two  points,  they  identified  and 
classified  different  types  of  trust  that  may  be  required  in  an  authentication  procedure.  Trust  with 
respect  to  keeping  secrets,  providing  recommendations,  and  performing  correctly  algorithmic  steps 
are  some  examples.  They  then  proposed  a  language  for  expressing  trust  relations  and  an  algorithm 
for  deriving  trust  relations  from  recommendations.  Finally,  they  analyzed  several  authentication 
protocols  with  respect  to  their  trust  requirements.  But  because  the  trust  specification  language 
is  not  embedded  in  an  analysis  formalism,  all  their  analyses  are  informal.  This  trust  specification 
language  was  later  extended  to  include  valued  trust  relationships  [8].  Using  the  extended  language, 
one  can  express  to  what  degree  one  party  trusts  another  in  some  specific  respect. 

Logic  based  protocol  analysis  methods  [76,  19,  46]  have  incorporated  some  notion  of  trust.  For 
example,  BAN  [19]  has  a  language  construct  for  formalizing  the  notion  of  who  can  be  trusted 
on  what  (for  example,  a  key  server  can  be  trusted  on  key  generation),  and  an  inference  rule 
for  incorporating  a  trusted  party’s  belief  into  other  parties’  belief  set.  In  all  these  logics,  trust 
specifications  are  part  of  the  initial  assumptions  of  a  system,  and  used  as  axioms  to  draw  conclusions 
about  security  properties  of  a  protocol. 

In  commerce  transactions,  trusted  intermediaries  can  be  used  to  enable  exchanges  between  two 
mutually  distrustful  parties.  When  three  or  more  such  parties  attempt  to  exchange  multiple  items 
among  themselves,  and  there  is  no  single  intermediary  that  is  trusted  by  them  all,  relevant  questions 
to  ask  are:  Can  such  an  exchange  be  feasibly  carried  out,  in  the  sense  that  no  participant  ever  risks 
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losing  money  or  goods  without  receiving  everything  promised  in  exchange?  And  if  so,  what  are 
the  steps  [58]?  To  answer  these  questions,  Ketchpel  and  Garcia-Molina  introduces  1)  a  graphical 
notation  in  which  one  can  represent  parties  (both  exchanging  parties  and  intermediaries)  involved 
in  a  transaction  and  the  interactions  between  them;  and  2)  a  method  for  finding  a  sequence  of 
pairwise  mediated  exchanges  that  will  lead  to  a  feasible  global  exchange,  if  one  exists.  Note  that 
this  work  does  not  attempt  to  dissect  the  notion  of  trust.  Rather,  it  models  trust  at  a  higher  level 
of  abstraction,  simply  as  a  factor  that  guarantees  successful  two-way  exchanges. 

Finally,  Branstad  et  al  investigated  the  role  of  trust  in  TMail,  a  privacy-enhanced  electronic 
mail  system  [18].  This  work  is  the  closest  in  spirit  to  our  effort  in  making  trust  assumptions 
explicit.  They  identify  functions  (both  cryptographic  and  non-cryptographic)  that  need  to  execute 
correctly  so  that  electronic  mail  remains  protected.  They  then  argue  that  these  functions  need  to 
be  hosted  in  a  trusted  computing  base  so  that  their  correct  execution  can  be  assured.  They  also 
discuss  possible  attacks  to  the  mail  system  if  these  critical  functions  are  running  in  an  untrusted 
computing  base.  The  discussion  is  all  informal,  and  there  is  no  attempt  to  formalize  these  ideas  in 
the  paper. 

1.7  Roadmap 

The  rest  of  this  dissertation  consists  logically  of  three  parts.  In  the  first  part  (Chapter  2),  we 
present  our  specification,  modeling,  and  analysis  framework.  We  start  with  a  characterization  of 
electronic  commerce  systems  as  they  are  modeled  in  this  dissertation.  We  then  present  a  standard 
state  machine  formalization  of  such  systems  and  a  formalism  for  protocol  specification.  Finally,  we 
define  different  types  of  executions  of  a  protocol,  which  we  then  use  to  give  a  formal  definition  of 
p-protective  protocols. 

In  the  second  part  (Chapters  3  -  5),  we  apply  the  framework  from  Chapter  2  to  specify  and 
analyze  three  protocols:  we  specify  and  analyze  Franklin  and  Reiter’s  fair  exchange  protocol  using 
semi-trusted  third  parties  [42]  in  Chapter  3;  NetBill  [28]  in  Chapter  4;  and  Brands’s  off-line  elec¬ 
tronic  cash  with  observers  protocol  [14]  in  Chapter  5.  These  chapters  follow  the  same  structure. 
First  we  introduce  the  protocol  and  justify  why  it  makes  an  interesting  case  study.  We  then  present 
an  abstract  formulation  of  mathematical  (cryptographic)  building  blocks  used  by  the  protocol.  A 
specification  of  the  protocol  and  its  various  protection  properties  appears  next,  and  is  followed  by 
a  high-level  analysis  of  the  protocol,  the  main  results,  and  detailed  proofs.  The  chapters  conclude 
with  a  summary  of  the  findings  of  our  analysis  and  a  discussion  of  insights  gained  through  the 
exercise. 

The  last  part  (Chapter  6)  presents  our  conclusions,  summarizes  the  dissertation,  reflects  on  our 
contributions,  and  proposes  directions  for  future  work. 
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Chapter  2 

The  Model 


In  this  chapter,  we  present  the  model  we  use  to  analyze  electronic  commerce  protocols  with  respect 
to  protection  of  individuals’  interests.  In  Section  2.1,  we  characterize  electronic  commerce  systems 
as  they  are  formalized  in  this  work.  This  characterization  departs  from  traditional  characterizations 
of  security  and  electronic  commerce  systems  in  two  ways:  in  the  failure  model  of  the  participants 
of  a  protocol  and  in  the  security  of  communications.  In  traditional  characterizations,  participants 
of  a  protocol  always  behave  correctly,  and  there  is  invariably  an  intruder  that  can  eavesdrop  and 
corrupt  communications  among  the  participants.  In  our  characterization,  participants  of  a  protocol, 
including  trusted  parties,  may  fail  or  misbehave,  but  communications  among  them  are  assumed  to 
be  secure. 

In  Section  2.2,  we  present  a  standard  state  machine  formalization  of  electronic  commerce  sys¬ 
tems.  The  formalization  models  what  electronic  commerce  systems  can  do  in  general,  independently 
of  any  protocol  they  might  be  running. 

In  Section  2.3,  we  present  the  formalism  we  use  to  specify  protocols.  Our  formalism  is  state- 
based  in  that  it  uses  a  set  of  protocol  rules  to  specify  state  conditions  and  protocol  steps  they 
enable.  In  addition  to  the  standard  initial  condition  and  protocol  rules,  our  formalism  incorporates 
the  trust  assumptions  of  a  protocol  as  a  component  of  protocol  specifications. 

To  analyze  a  protocol  in  a  model-theoretic  setting,  one  examines  the  set  of  all  of  its  executions. 
In  Section  2.4,  we  define  different  sets  of  executions  of  a  protocol,  which  are  then  used  to  give  a 
formal  definition  of  p-protective  protocols. 

2.1  System  Characterization  and  Assumptions 

Electronic  commerce  systems  consist  of  sets  of  interconnected  agents:  banks,  shops,  individual 
customers,  etc.  At  any  time,  these  agents  may  be  running  multiple  processes  simultaneously,  each 
process  carrying  out  a  different  transaction1  with  a  different  agent.  In  our  model,  we  assume  that 
each  agent  runs  one  process  at  a  time,  and  identify  agents  with  the  processes  they  run. 

In  our  model,  processes  have  private  local  stores:  the  data  they  hold  are  not  publicly  accessible. 
Processes  can  generate  new  data  -  e.g.,  keys  and  nonces  -  and  communicate  with  each  other  by 
message  passing.  They  also  have  timing  capabilities  and  can  timeout  while  waiting  for  events  to 
occur.  Finally,  they  have  cryptographic  capabilities  such  as  encryption  and  decryption,  which  allow 

1  Unless  otherwise  stated,  transaction  is  used  in  an  informal,  non-techmcal  sense  in  this  dissertation. 
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them  to  derive  new  data  from  existing  ones. 

The  interprocess  communication  subsystem  logically  consists  of  end-to-end,  pairwise  commu¬ 
nication  channels.  Each  channel  models  all  the  hardware  and  software  that  connect  the  two  end- 
processes.  Communication  is  connection-oriented  (FIFO,  at-most-once  message  delivery),  and  we 
assume  connections  are  established  at  the  beginning  of  transactions. 

In  our  model,  both  the  communication  and  process  executions  are  asynchronous :  communica¬ 
tion  delays  are  unbounded,  and  processes  can  take  steps  at  arbitrary  speeds. 

In  this  dissertation,  we  consider  both  process  failures  and  channel  failures.  We  cast  them  all 
in  terms  of  process  failures,  however,  because  in  our  model  communication  is  connection-oriented 
and  channel  failures  manifest  themselves  in  the  processes.  For  the  purposes  of  this  work,  processes 
can  fail  in  two  ways:  they  can  failstop  or  they  can  deceive. 

If  a  process  failstops,  it  terminates  abnormally,  i.e.,  in  a  way  not  prescribed  by  the  algorithm 
it  is  running.  Abnormal  terminations  can  be  caused  by  local  or  remote  factors.  Power  outages, 
computer  crashes,  and  user-initiated  interruptions  are  all  examples  of  local  factors.  Connection 
failures  due  to  problems  at  remote  processes  or  with  communication  channels  are  examples  of 
remote  factors. 

If  a  process  deceives,  it  follows  the  algorithm  only  “apparently”.  Roughly  speaking,  even 
though  the  types  of  events  that  occur  at  each  step  are  those  prescribed  by  the  algorithm,  the 
messages  they  carry  may  not  be.  For  example,  sending  a  message  that  is  not  the  one  prescribed 
by  the  algorithm  according  to  the  process’s  present  state  is  a  deception.  Deceptions  only  occur  by 
Byzantine  processes.  We  do  not  call  processes  that  deceive  “Byzantine  processes,”  however,  because 
they  do  not  fail  in  all  the  ways  that  Byzantine  processes  can,  as  defined  in  the  literature  [36]. 

We  consider  these  types  of  failures  because  they  model  simple,  yet  realistic  attacks  to  electronic 
commerce  systems.  Power  outages,  computer  crashes,  and  user-initiated  interruptions  can  all 
cause  premature  termination  of  a  process;  connection  failures  are  common  with  today’s  Internet; 
and  deceptions  can  be  easily  carried  out  by  malicious  users. 

Finally,  we  assume  communication  is  secure:  if  a  message  is  received,  then  it  is  received  by  the 
intended  recipient,  authenticated,  confidential,  and  intact  (untampered).  Effectively,  we  assume 
that  processes  use  the  service  of  an  underlying  layer  of  security  protocols.  This  assumption  allows  us 
to  abstract  away  possible  spoofings,  sniffings,  and  tamperings  of  messages  by  third  party  intruders 
and  makes  modeling  of  intruders  unnecessary. 

Discussion 

Our  model  of  electronic  commerce  systems  makes  simplifying  assumptions  that  have  impact 
on  protection  properties  of  a  transaction.  For  example,  concurrent  execution  of  two  transactions 
is  known  to  cause  problems  in  traditional  distributed  systems;  it  also  leads  to  subtle  problems  in 
cryptographic  protocols  [63].  Message  tampering  can  prevent  original  messages  from  reaching  their 
intended  destinations,  which  can  also  compromise  protection  of  different  parties. 

In  a  first  step  towards  formalizing  and  understanding  protection  of  individuals’  interests,  how¬ 
ever,  we  purposely  abstract  away  as  much  detail  as  possible,  and  focus  on  what  participants  of 
a  transaction  with  the  “help”  of  unreliable  communication  channels  can  do  to  compromise  other 
participants’  interests.  This  allows  us  to  address  core  questions,  such  as  “How  can  we  characterize 
precisely  the  notion  of  protection?”,  “How  can  we  formalize  trust  assumptions?”,  and  “How  do  we 
use  trust  assumptions  in  the  analyses  of  protocols?”,  independently  of  issues  like  concurrency  and 
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communication  security.  After  addressing  these  questions,  we  can  then  relax  our  assumptions  and 
investigate  how  protection  interacts  with  these  issues. 

For  a  more  complete  list  of  assumptions  we  make  and  their  implications,  see  Section  2.5. 


2.2  Modeling  Electronic  Commerce  Systems  as  Transition  Sys¬ 
tems 

In  this  section,  we  present  a  state  machine  model  for  electronic  commerce  systems.  We  model 
single  processes  as  simple  transition  systems  and  electronic  commerce  systems  as  asynchronous 
compositions  of  these  simple  systems.  Most  of  the  formalization  is  standard,  and  we  include  it  here 
for  self-containment.  The  few  non-standard  features  will  be  explained  in  detail. 

We  start  formalizing  some  message-related  concepts. 

2.2.1  Messages 

In  our  model,  messages  can  be  basic  messages  or  composite  messages.  Basic  messages  are  those 
simplest  units  of  data,  such  as  keys,  product  ids,  and  prices,  that  cannot  be  further  decomposed. 
Basic  messages  can  be  concatenated  or  used  as  arguments  of  cryptographic  functions;  the  result  is 
composite  messages. 

Cryptographic  functions  are  functions  such  as  encryption,  decryption,  and  signing  functions.  In 
our  model,  they  are  abstract  functions  satisfying  certain  ideal  properties.  We  reserve  further  discus¬ 
sion  and  formalization  of  cryptographic  functions  for  later  chapters,  when  they  will  be  introduced 
in  the  context  of  particular  protocols. 

In  what  follows,  we  formalize  message-related  concepts.  The  notion  of  type  is  used  informally 
here:  a  type  is  simply  a  domain  from  which  a  particular  class  of  messages  can  be  drawn. 

Def.  2.1  says  that  messages  are  built  inductively  from  basic  messages  by  applying  concatenation 
and  cryptographic  functions. 

Definition  2.1  Messages  are  inductively  defined  as: 

1.  Basic  messages  m  of  type  t,  m  :t,  are  messages; 

2.  If  m i  :  t\  and  m2  :  £2  are  messages,  then  the  concatenation  m\m2  :  h  X  £2  of  m\  and  m2  is 
a  message; 

3.  J//:t1x...xin->t  is  a  cryptographic  function  and  mi  :  ti  are  messages,  then  the  function 
application  of  f  to  m\, . . . ,  mn,  /(mi, ...,  mn)  :  t,  is  a  message. 

Definition  2.2  defines  when  two  messages  are  equal.  It  assumes  that  each  type  of  basic  messages 
comes  with  a  definition  of  identity  between  messages  of  that  type. 

Definition  2.2  Let  m  and  m!  be  two  messages,  m  equals  m!  (to  =msg  to')  if  and  only  if 

1.  m  and  m'  are  identical  basic  messages; 

2.  to  =  To! m2;  to'  =  m!xm'2;  and  mi  =msg  to'-,  for  i  =  1,  2;  or 

S.  to  =  f(mu...,mn);  to'  =  f(m[,.  ..,m'n);  and  mi  =msg  to',  for  i  =  1,  ...,  n. 
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In  the  rest  of  this  dissertation,  we  represent  =m$g  by  =.  It  should  be  clear  from  the  context  whether 
a  equality  sign  denotes  equality  between  messages  as  defined  in  Def.  2.2  or  is  being  used  informally 
to  denote  a  mathematical  equality. 

Once  we  have  defined  message  equality,  we  can  define  associativity.  Concatenation  of  messages 
is  associative.  That  is,  (mim2)m3  =  m  \  (rn^mfi.  For  simplicity,  we  sometimes  represent  them  by 
mym.2‘mz. 

Message  equality  will  be  later  extended  with  conversions  between  cryptographic  terms.  A 
familiar  example  of  conversion  says  that  the  result  of  encrypting  and  then  decrypting  a  message 
(with  the  same  symmetric  key)  is  the  message  itself.  That  is 

dec(enc(m ,  k) ,  k)  =  m, 

where  =  denotes  conversion.  The  conversion  relation  creates  an  equivalence  class  of  equal  messages. 
That  is, 

If  mi  =  m2,  then  mi  —  m2- 

From  Def.  2.1,  we  can  derive  the  submessage  relation  between  two  messages.  Any  message 
is  a  submessage  of  itself,  and  any  submessage  of  messages  mt-  in  points  2  and  3  of  Def.  2.1  is  a 
submessage  of  m.  We  use  C  to  denote  the  submessage  relation:  m'  C  m  denotes  m'  is  a  submessage 
of  m.  The  notion  of  submessages  of  a  message  will  be  used  later  to  formalize  the  notion  of  freshness 
of  messages  generated  at  random. 

Given  a  set  of  messages  M,  we  can  use  concatenation,  decomposition,  and  function  application 
to  derive  new  messages: 

Definition  2.3  Let  m  be  a  message  and  M  be  a  set  of  messages,  m  is  constructive  from  M, 
m  £*  M,  if  and  only  if 

1.  m  £  M ,  or 

2.  m  =  m1ra2,  mi  £*  M  and  m2  £*  M,  or 

3.  m  =  mi,  for  i  =  1  or  i  =  2,  and  mim2  £*  M,  or 

4.  m  =  /(mlt...,mn),  andVi  £  {1  ,...,n},  m ,  £*  M. 

Definition  2.3  says  that  m  is  constructive  from  M  if  1)  m  is  a  member  of  M;  2)  m  is  a 
concatenation  of  two  messages  mi  and  m2,  both  of  which  are  constructive  from  M;  3)  m  is  a 
component  of  a  concatenated  message  constructive  from  from  M ;  or  4)  m  is  the  result  of  applying 
a  cryptographic  function  to  inputs  mi, . . .,  mn,  all  of  which  are  constructive  from  M. 

2.2.2  Modeling  processes 

We  model  processes  as  automata  that  take  steps  to  go  from  one  state  to  another.  Formally,  they 
are  represented  by  transition  systems. 

Definition  2.4  Let  V  be  a  process.  Then  V  is  represented  by  a  tuple  <  S,  /: .  r,  So  >  where: 

•  E  is  a  ( possibly  infinite )  set  of  states; 
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•  E  is  a  set  of  events; 

There  are  different  types  of  events: 

—  exit:  normal  process  termination; 

—  failLocal:  abnormal  process  termination,  caused  by  local  conditions  such  as  system  crashes 
or  deliberate  user  interruptions; 

—  failRemote:  abnormal  process  termination  caused  by  communication  failures; 

—  send{p ,  m) :  message  m  is  sent  to  process  p; 

—  receive(p,  m) :  message  m  is  received  from  process  p; 

—  timeout:  handles  event  delays; 

—  random{b):  Random  generation  of  a  basic  message  b.  Messages  generated  at  random  are 
globally  fresh  and  cannot  be  guessed  or  otherwise  computed  by  anyone. 

•  t  is  a  transition  relation  of  type  £  X  E  X  £; 

r  can  be  a  partial  relation,  i.e.,  for  some  pairs  of  states  s  and  s',  there  may  not  exist  an  event 
e  such  that  ( s ,  e,  s')  is  a  valid  state  transition.  There  exist  system-level  constraints  that  make 
a  tuple  (s,  e,  s’)  an  invalid  transition.  We  formalize  these  constraints  later  in  this  subsection. 

•  Eo  C  E  is  a  set  of  initial  states. 

Valid  State  Transitions 

In  Def.  2.4,  states  were  introduced  as  abstract  entities  without  any  internal  structure.  To  model 
processes  as  entities  that  can  accumulate,  send,  and  receive  messages,  however,  we  need  to  keep 
track  of  messages  available  to  the  processes  at  each  state.  We  use  a  state  variable  MS  (For  Message 
Set)  to  model  this  set  of  messages.  Intuitively,  a  process  starts  with  a  certain  set  of  messages  and, 
as  it  transitions  from  one  state  to  another,  this  set  changes  according  to  well-defined  rules  shown 
in  Def.  2.5.  These  rules  characterize  valid  state  transitions. 

In  what  follows,  we  use  s(v)  to  denote  the  value  of  variable  v  at  state  s. 

Definition  2.5  Valid  state  transitions 

Let  ( s ,  e,  s')  6  t  be  a  state  transition.  Then: 

1.  If  e  =  send(p,m),  then  m  G*  s(MS); 

2.  If  e  =  receive(p,m)  or  e  =  random(m),  then  s' (MS)  =  s(MS)  U  {m}; 

3.  If  e  =  randomfb),  then  jBm  €  s(MS)  such  that  b  C  m; 

4-  If  e  =  exit  or  e  =  failLocal  or  e  —  timeout  or  e  =  failRemote  or  e  =  send(p,m),  then 
s' (MS)  =  s(MS) . 

According  to  Definition  2.5,  processes  can  send  only  messages  constructive  from  messages 
available  at  s;  messages  received  or  randomly  generated  by  a  process  are  available  to  the  process 
at  s';  if  a  basic  message  b  is  randomly  generated,  then  b  cannot  be  a  submessage  of  a  message 
available  at  s,  i.e.,  b  is  fresh;  and  exit,  failLocal,  timeout,  failRemote ,  and  send  preserve  the  set  of 
available  messages.  We  call  condition  3  the  random  generation  condition. 
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Local  Computations 

The  specification  of  a  transition  system  S  determines  the  set  of  S’s  computations.  Def.  2.6  is 
standard. 

Definition  2.6  Local  Computations 

Let  a  :  sq  ei  s\  . . .  be  an  alternating  sequence  of  states  and  events  and  S  =<  S,  E ,  r,  So  >  be 
a  simple  transition  system,  a  is  a  computation  of  S  if  and  only  if  o  is  such  that 

1.  So  €  So; 

2.  For  all  subsequences  s{  ei+1  si+1  in  a,  i  =  0, 1, . . su  si+1  6  E,  ei+1  €  E,  and  (s,-,  ei+usi+1)  e 
t; 

S.  If  a  is  finite ,  then  the  last  element  of  o  is  a  state; 

4-  Given  a  subsequence  S{  e;+i  Sj+i  in  a,  if  e^i  G  {exit,  failLocal ,  failRemote},  then  a  is  finite 
and  S{. j_i  is  the  last  state  of  a. 

2.2.3  Modeling  Electronic  Commerce  Systems 

As  systems  formed  by  concurrent,  asynchronous  distributed  processes,  electronic  commerce  systems 
can  be  modeled  by  compositions  where  component  state  machines  -  modeling  individual  processes 
-  take  turns  in  making  state  transitions.  We  compose  our  systems  using  the  standard  asynchronous 
composition  [2].  In  what  follows,  we  assume  the  existence  of  a  global  synchronized  clock.  In  its 
absence,  we  can  always  resort  to  Lamport  clocks  [60],  which  takes  into  account  causal  dependencies 
among  the  events  in  a  system. 

We  now  present  the  composition  and  computations  they  determine,  starting  with  some  auxiliary 
definitions. 

Auxiliary  Definitions 
Definition  2.7  Disjoint  union 

Given  sets  Si, ... ,  Sn,  we  can  define  S  =  Si  l±l  . . .  (±J  Sn,  the  disjoint  union  of  Si, . . . ,  Sn,  as 
follows: 

a  G  S{  cd  G  S. 

Intuitively,  the  elements  of  a  disjoint  union  are  elements  from  the  component  sets  tagged  with 
superscripts  indicating  the  set  to  which  they  originally  belong. 

In  Def.  2.8,  we  use  the  notion  of  equality  of  events,  whose  definition  is  as  expected.  Given  two 
events  e  and  e',  e  =  ef  if  and  only  if  they  are  the  same  type  of  event  and  their  parameters  [send, 
receive ,  and  random  have  parameters)  are  equal. 

Definition  2.8  Instances  of  an  event 

Let  cr  \  So  e\  s\  ...  be  an  alternating  sequence  of  states  and  events,  ei  and  ej  are  instances  of 
the  same  event ,  if  i  ^  j  and  ei  =  ej. 
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Composition 

Definition  2.9  Let  Si,  ...Sn  be  simple  transition  systems  modeling  individual  processes  pi ,  ...,pn- 
If  Si  =<  Sj,  Ei,  E0;  >,  Vi  e  {1, . . . ,  n},  then  the  system  formed  by  pu  . . . ,  pn  can  be  modeled  by 
a  composite  transition  system  S  =<  E,  E,t,  Eo  >  ■  defined  as  follows: 

1.  E  =  Ex  X  ...  X  En; 

2.  E  =  Ei  (+) . . .  1+1  En; 

3.  t  :  E  X  E  x  E  is  defined  as  follows: 


(s,  e,  s')  6  r  if  and  only  i f 


3  i  such  that 

s  —  (si, . . . )  Sj, . . . ,  sn)  A  s  =  (si , . . . ,  Sj, . . . ,  sn)  A  e  e  A 
e  Ti  A 

ez  =  random(b)  -> flm  G  U£=i  *A;(MS)  such  that  b\Zm. 


Jf.  So  —  5^01  X  ...  X  Son* 

Def.  2.9  (3)  says  that  only  one  process  takes  a  step  in  each  global  state  transition,  and  not  all  local 
state  transitions  can  derive  global  state  transitions.  If  a  local  state  transition  (5,  e,  s')  is  such  that 
e  =  random (6),  it  cannot  derive  a  global  state  transition  unless  it  satisfies  the  random  generation 
condition,  which  requires  b  to  be  globally  fresh. 


System  Computations 

As  with  simple  transition  systems,  specification  of  a  composite  transition  system  S  also  determines 
<S’s  computations. 

Definition  2.10  System  Computations 

Let  o  :  So  ei  Si  ...  be  an  alternating  sequence  of  states  and  events ,  and  S  =<  E,  E,  r,  Eo  >  be 
a  composite  transition  system,  a  is  a  computation  of  S,  if  and  only  if  a  is  such  that 

1.  so  £  So! 

2.  For  all  subsequences  Si  ei+i  Si+ 1  in  a,  i  =  0, 1, . .  v  Si,  s*+i  ^  S,  e^i  6  E,  and  (s*,  e2-+i,  s*+i)  € 

r; 

3.  If  a  is  finite,  then  the  last  element  of  a  is  a  state; 

4 .  Given  a  subsequence  S{  S{+ \  in  a,  if  G  { exitp , failLocaf ,  failRemot ef},  then  there 
does  not  exist  e  j ,  j  >  i  +  1,  such  that  ej  =  ep ; 

5.  If  a  is  infinite,  then  it  satisfies  weak  ( process )  fairness ,  as  defined  in  [6  7]\ 

6.  If  a  =  receiveg(p,m)  G  o,  then  3ej  G  <7,  j  <  i  such  that  ej  =  sendP(q,m ); 

7.  For  each  instance  of  sendp(q,m)  G  a,  there  exists  at  most  one  corresponding  receive9  (p,m). 
And  for  all  corresponding  sends  and  receives,  ei  —  sendP{q ,  m)  and  ej  =  receive9  (p,  m),  i  <  j. 
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8.  If  ti  —  receiveq(p ,  mi),  e3  —  receive*1  (p,  1112),  and  i  <  j,  then  there  exist  events e^  =  sendP(q ,  mi), 
ey  =  sendP^q,  m2),  and  i!  <  jl . 

Conditions  1-3  are  exactly  those  required  of  computations  of  simple  transition  systems.  Con¬ 
dition  4  corresponds  to  condition  4  in  Def.  2.6  and  says  that  a  component  transition  system  cannot 
make  further  progress  once  it  experiences  exit ,  failLocal  or  failRemote  events.  Condition  5  requires 
that  computations  of  composite  transition  system  be  fair  interleavings  of  computations  of  the  com¬ 
ponent  transition  systems.  Conditions  6  —  8  model  interprocess  communication :  a  message  needs 
to  be  sent  before  it  can  be  received;  messages  are  received  at  most  once;  and  in  a  FIFO  manner. 
Messages  are  received  at  most  once  because  communication  is  unreliable  in  our  model;  there  can 
be  transmission  delays  and  channel  failures.  (A  message  cannot  be  received  multiple  times  because 
the  communication  is  connection-oriented.) 

In  the  rest  of  this  dissertation,  we  call  condition  6  the  communication  assumption . 

Definition  2,11  Projections 

Let  a  :  $q  e\  S\  ...  be  a  computation  of  a  system  S ,  whose  components  are  Si  ~<  Ui ,  Et*,  E{,  r*,  qi  >, 

1  =  1, . . n.  a  \  p,  projection  of  a  along  component  Sp,  is  the  sequence  obtained  by  deleting  each 
pair  er  sr  for  which  er  is  not  an  event  of  Sp,  and  replacing  each  remaining  sr  by  s automaton 
Sp  ’ s  component  of  the  state  sr. 

Projections  are  computations.  Intuitively,  a  |  p  captures  the  computation  that  takes  place  at 
node  p ,  while  a  takes  place  at  the  system  as  a  whole. 

Intuitively,  if  a  is  a  system  computation,  then  a  \  p  captures  the  node  p’s  local  computation. 


2.3  Protocol  Specification 

Before  a  protocol  can  be  formally  analyzed,  it  needs  to  be  formally  specified.  In  this  dissertation, 
a  formal  protocol  specification  consists  of: 

•  A  finite  set  P  =  {p1) . . .  ,pn}  of  principals; 

•  An  initial  condition  /; 

•  A  principal-indexed  collection  R  =  {i?Pl, . . .  :RPn }  of  local  protocols;  and 

•  A  principal-indexed  collection  T  =  {TPl, . . TPn}  of  trust  assumptions. 

All,  except  trust  assumptions,  are  standard  components  in  protocol  specifications. 

In  what  follows,  state  variables  are  in  typewriter  font  and  state  formulas  are  first-order  for¬ 
mulas  defined  in  a  standard  way  [67]. 

2.3.1  Specification  of  Initial  Conditions 

Initial  conditions  determine  what  needs  to  hold  in  the  beginning  of  protocol  executions.  They 
determine  whether  a  message  is  public,  private,  or  shareable  among  a  subset  of  principals,  and  how 
the  message  relates  to  other  messages  in  the  system.  For  example,  they  specify  that  if  a  principal 
A  holds  a  key  k,  thought  of  as  principal  5’s  public  key,  and  Ar1  is  B: s  private  key,  then  k  is  the 
public  counterpart  of  A;-1. 
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Initial  conditions  are  specified  by  state  formulas.  State  formulas  specifying  initial  conditions 
may  include  a  non-standard  predicate  shareable  to  specify  which  principals  may  share  a  message 
at  the  initial  state. 

Formally,  given  a  state  s  and  an  initial  condition  I  (or  more  generally  a  state  formula  F),  the 
definition  of  s  satisfies  I  ( s  satisfies  F),  s  \=  I  (s  \=  F),  is  standard  [67],  with  the  interpretation  of 
shareable  defined  as  follows: 

Definition  2.3.1  Let  s  be  a  state,  P'  C  P  be  a  set  of  principals,  and  m  be  a  message. 

s  |=  shareable(m,  P '),  if  Vp  €  P  —  P1  ,m  sp(MS). 

Def.  2.3.1  says  that  m  is  shareable  among  principals  pi  G  P'  if  m  may  be  found  only  in  the  local 
stores  of  principals  p  €  F'.  Note  that  m  is  not  required  to  be  in  each  pfis  local  store;  instead,  it  is 
required  to  not  be  in  the  local  stores  of  processes  pj  6  (F  -  P'). 

In  Example  2.3.2, 1  specifies  that  k~l  is  C’s  private  key: 

Example  2.3.2  Let  kc  and  kf1  be  messages  and  A,  B,  C  be  principals. 

I  =  keyPair(fcc,  kf1)  A  shareable^"1,  {C})  A  shareable(fcc,  {A,  B,  C}) 

specifies  that  kc  is  a  public  key  whose  corresponding  private  key  is  k~l ;  kf1  is  private  to  C;  and  kc 
is  shareable  by  A,  B,  and  C. 

2.3.2  Specification  of  Local  Protocols 

A  local  protocol  Rv  consists  of  a  set  of  rules  r  of  the  form: 

r  :  Tj  =$■  { E\ , . . . ,  Em  } , 

where  p  is  a  state  formula  and  Efs  are  event-templates  —  events  whose  parameters  contain  variables 
-  of  types  exit,  timeout,  send,  receive ,  and  random.  FailLocal  and  failRemote  do  not  appear  in 
protocol  rules  because  they  model  abnormal  terminations. 

Intuitively,  p  ( enabling  condition )  determines  the  state  condition  under  which  r  is  applicable, 
and  Ei, . . . ,  Em  ( protocol  steps )  prescribe  alternative  events  a  process  should  go  through  from  states 
satisfying  p.  The  non-deterministic  choice  of  which  event  is  taken  is  made  by  the  environment. 

A  local  protocol  needs  to  specify  its  valid  sequences  of  steps,  as  well  as  messages  sent/received 
at  each  step.  A  specification  for  the  protocol  in  Fig.  1.1,  for  example,  needs  to  specify  that  T  can 
send  a  message  to  A  only  after  T  has  received  messages  from  both  A  and  B.  Furthermore,  it  needs 
to  specify  that  the  message  T  sends  to  A  is  the  one  it  received  from  B. 

To  be  able  to  specify  message  flows  that  a  protocol  prescribes,  one  should  have  ways  of  talking 
about  the  sequence  of  events  a  process  has  experienced  up  to  any  given  state.  One  way  of  making 
this  possible  is  to  add  another  state  variable  to  the  processes.  This  variable  should  keep  track  of  the 
sequence  of  events  a  process  has  experienced  so  far.  In  our  model,  this  variable  is  H  (for  History). 

Given  a  state  s,  s(H)  is  a  sequence  ex, . .  .,em  of  events,  em  being  the  one  most  recently  experi¬ 
enced  by  the  process.  Given  a  computation  a  :  «o  ei  $1  ■  •  •  of  a  process,  s(H)  satisfies  the  following 
conditions: 

|  s0(H)  =  6,  and  ^.l) 

|  si+i(H)  =  append (si(H),ei+i) 

We  add  these  conditions  to  those  in  Def.  2.6  of  computations. 

Using  variable  H,  local  protocol  rules  typically  appear  as  follows: 
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Example  2.12  An  example  of  a  protocol  rule: 

3x  :  t.Coin  |  last( H)  =  receive(M,x)  {send(N,  x),  receive(M,y  :  LReceipt),  timeout} 

It  says  that  if  the  last  event  experienced  by  a  principal  is  receiving  a  message  of  type  ECoin  from 
principal  M,  then  any  of  the  following  three  types  of  events  may  occur  next.  The  principal  may 
send  the  message  it  received  from  M  to  N,  it  may  receive  a  message  of  type  t-Receipt  from  M,  or  it 
may  timeout  while  waiting  for  the  receive  event  to  occur. 

2.3.3  Specification  of  Trust  Assumptions 

Given  a  principal  p,  its  trust  assumptions  Tv  consists  of  a  set  {ri, . . . ,  77J  of  formulas  in  linear  time 
temporal  logic  [67]  over  a  sequence  of  states.  Effectively,  we  only  make  trust  assumptions  about 
trusted  parties.  If  p  is  not  a  trusted  party,  Tp  =  true. 

Example  2.13  The  following  is  an  example  of  a  trust  assumption : 

Vz,  □(send(M,  z)  G  H  — >  receive(C\x)  €  H). 

It  says  that  the  principal  is  trusted  to  send  M  only  messages  it  receives  from  C . 

As  discussed  in  Section  1.3,  trust  assumptions  are  protocol-specific  assumptions  about  how 
trusted  parties  ought  to  behave.  For  protocols  that  we  have  investigated,  they  can  all  be  formalized 
in  linear  time  temporal  logic.  Not  all  linear  time  temporal  logic  formulas  are  formalizations  of  trust 
assumptions,  however.  To  be  a  trust  assumption,  a  formula  needs  to  express  a  condition  that  can 
be  satisfied  by  compliant2  trusted  parties  and  that,  if  violated,  can  compromise  the  individual 
interests  of  a  second  principal  who  relies  on  that  trusted  behavior.  What  makes  a  temporal  logic 
formula  a  trust  assumption  therefore  is  its  semantics  rather  than  its  syntax. 

2.4  Formalizing  ^-Protective  Protocols  in  Our  Model 

In  Section  1.4.3,  we  introduced  an  informal  characterization  of  p-protective  protocols.  In  this  sec¬ 
tion,  we  formalize  that  characterization  in  the  context  of  our  model.  We  first  give  some  preliminary 
definitions  (Section  2.4.1).  Then  we  define  a  number  of  different  types  of  executions  used  to  char¬ 
acterize  p- protective  protocols  (Section  2.4.2).  Finally,  we  formalize  the  concept  of  p-protective 
protocols  itself  (Section  2.4.3). 

2.4.1  Preliminaries 

In  this  subsection,  we  give  three  definitions  used  in  defining  different  types  of  executions  in  Sec¬ 
tion  2.4.2.  Def.  2.14  defines  when  a  state  transition  ( s  e  s')  complies  with  a  protocol  rule  r. 
Def.  2.16  defines  when  (s  e  s')  deceptively- complies  with  r.  And  Def.  2.11  defines  a  projection  of  a 
computation  along  one  of  its  component  automata. 

In  what  follows,  the  definition  of  instantiation  of  an  event-template  E  is  standard.  An  event  e 
is  an  instantiation  of  E  if  there  is  a  substitution  \x\fmi, . . .,  xnjmyf\  for  free  variables  a?i, . .  .  ,#n 
in  E  such  that  e  =  E[xi/m\,  . . .,  xn/mn\. 

2 Compliance  is  being  used  informally  here.  See  its  formal  definition  in  Section  2.4.2. 
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Definition  2.14  Let  ( s  e  s')  be  a  state  transition  and  r  :  g  =$■  {E\, . . . ,  En}  be  a  protocol  rule. 
(s  e  s')  complies  with  r, 

(s  e  s')  |=  r, 


if  and  only  if: 


1.  s  |=  g;  and 

2.  (a)  3E{  €  {Ei,...,En}  such  that  e  is  an  instantiation  of  Erf,  where  0  is  a  substitution  of 

bound  variables  in  Et  determined  by  s;  or 

(b)  3  Ei  €  {Ei, ...,  En)  such  that  Ei  specifies  a  send  or  a  receive  event,  and  e  =  failRemote. 


Intuitively,  (s  e  s')  complies  with  r,  if  g  is  satisfied  in  s,  and  (a)  e  is  an  instantiation  of  an  event- 
template  Ej  whose  bound  variables  are  substituted  according  to  the  protocol,  or  (b)  e  could  not 
be  a  send  or  receive  event,  as  specified  by  r,  because  of  a  communication  channel  failure. 

Note  that  since  (s  e  s')  is  a  valid  state  transition,  the  value  of  s'  cannot  be  arbitrary  (Defini¬ 
tion  2.5  and  conditions  2.1,  page  21).  This  justifies  why  we  do  not  have  explicit  conditions  on  s' 
in  Definition  2.14. 


Example  2.15  Let  (s  e  s')  be  a  state  transition  and 

r  :3x  :t\  receive(Y,a:)  G  H  =»  {receive(Z,  2  :  t  X  t),  send(Z,  x)}  be  a  protocol  rule. 

(s  e  s')  |=  r 

if  and  only  if  there  exists  a  message  m  :  t  such  that 

1.  receive(Y,m)  G  s(H),  and 

2.  (a)  e  —  receive(Z,  m'),  for  some  message  m'  :t  X  t;  or 

(b)  e  =  send(Z ,  m);  or 

(c)  e  =  failRemote. 

Note  that,  in  Example  2.15,  the  message  sent  to  Z  must  be  received  from  Y,  since  the  variable  x 
in  send(Z,  x)  is  bound. 

Definition  2.16  Let  (s  e  s')  be  a  state  transition  and  r  be  a  protocol  rule,  (s  e  s')  deceptively- 
complies  with  r 

(s  e  s')  \=d  r 

if  and  only  if: 

L  s  |=  77/  and 

2 .  3  E{  6  En}  such  that  e  is  an  instantiation  of  Ei,  but  e  is  not  an  instantiation  of  E{Q, 

where  6  is  a  substitution  of  bound  variables  in  r  determined  by  s. 
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Intuitively,  (s  e  s')  deceptively-com plies  with  r  if  77  is  satisfied  in  s  and  e  is  an  instantiation  of 
an  event-template  whose  bound  variables  are  not  substituted  according  to  the  protocol.  This 
is  a  deceptive  compliance  because  e  only  appears  as  an  event  prescribed  by  r;  it  is  not  an  event 
prescribed  by  r  because  its  message  parameters  are  not  instantiated  according  to  r  (the  bogus 
message  needs  to  have  the  right  type,  however). 

Note  that  in  Definition  2.16  the  enabling  condition  p  of  r  is  satisfied  in  s.  This  means  that  the 
state  transition  does  not  violate  the  conditions  for  the  firing  of  r,  which  typically  specifies  (explicit 
or  implicitly)  not  only  protocol  steps  that  should  have  happened,  but  also  specific  conditions  that 
these  previous  steps  must  satisfy. 

Deceptive  compliance  is  a  form  of  non-compliance.  A  second  form  of  non-compliance  is  intro¬ 
duced  in  Section  2.4.2. 

Example  2.17  Let  ( s  e  s')  be  a  state  transition,  and 

r  :3x  :t\  receive(Y,  a:)  £  H  =$>  {receive(Z,  2  :  t  x  f),send(Z,a:)}  be  a  protocol  rule. 

(s  e  s')  |=d  r 

if  and  only  if  there  exists  a  message  m  :  t  such  that 

1.  receive(Y,m)  £  s(H),  and 

2.  e  =  send(Z ,  m'),  where  m'  7^  m. 

Note  that,  in  Example  2.17,  the  message  sent  in  event  e  is  not  the  one  prescribed  by  r:  a  differ¬ 
ent  message  was  sent  instead.  Deceptive  compliance  will  be  used  later  to  characterize  deceptive 
executions,  where  a  process  apparently  follows  the  protocol  (the  order  and  the  format  of  message 
exchanges  are  as  prescribed  by  the  protocol),  but  cheats  by  using  arbitrary  messages. 

2.4.2  Protocol  Executions 

In  this  subsection,  we  define  different  types  of  protocol  executions  used  to  define  p-protective 
protocols.  We  obtain  these  protocol  executions  by  filtering  the  set  of  all  computations  by  protocol 
specifications.  Our  classification  (Fig.  2.1)  is  based  on  the  notion  of  compliance  and  takes  both  the 
type  and  the  source  of  failures  into  account.  We  also  define  trustworthy  executions ,  which  is  based 
on  the  trust  assumptions  of  a  protocol. 

Compliant,  Abortive,  and  Deceptive  Executions 

Traditionally,  protocol  executions  have  been  classified  according  to  failure  modes.  Classifications 
based  on  failure  modes  distinguish  executions  in  terms  of  whether  or  not  they  fail  and  how  they  fail. 
For  the  purpose  of  defining  p-protective  protocols,  however,  we  would  like  to  distinguish  executions 
in  terms  of  whether  or  not  their  corresponding  processes  comply  with  the  protocol,  and  how  they 
deviate  from  it.  Failure  and  deviation  differ  in  that  all  deviations  are  failures,  but  not  all  failures 
are  deviations.  The  key  factor  that  makes  a  failure  a  deviation  is  the  origin  of  the  failure.  If  the 
failure  is  attributed  to  local  causes,  then  it  is  a  deviation;  if  the  cause  is  remote,  then  it  is  not. 

Guided  by  the  notions  of  compliance  and  deviation,  we  propose  the  classification  shown  in 
Fig.  2.1.  It  is  based  on  our  classifying  failRemote  as  an  event  caused  by  remote  failures,  and  failLocal 
and  deceptive  steps  as  results  of  local  problems.  Intuitively,  this  classification  captures  the  notion 
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(  compliant:  failure-free  +  abnormal  termination  with  failRemote 


execution 


deviant 


abortive:  deviates  with  a  failLocal 

< 

deceptive:  deviates  with  deceptive  steps 


Figure  2.1:  Classification  of  local  protocol  executions. 


of  compliance  and  the  ways  in  which  one  can  deviate  from  compliance.  An  execution  is  compliant  if 
and  only  if  it  follows  the  local  protocol,  deviating  from  it  only  if  it  terminates  prematurely  because 
of  communication  problems.  An  execution  is  deviant  if  and  only  if  it  terminates  prematurely 
because  of  local  factors  or  it  deceives. 

We  formalize  the  various  executions  below. 

Definition  2.18  Compliant  executions  of  a  local  protocol 

Let  a  :  s0  ei  $i  . . .  be  a  computation  of  a  single  process  and  Rp  be  a  local  protocol  o  is  a 
compliant  execution  of  Rv  if  and  only  if 

V(st-  et*+x  Si+i)  G  a,  3r  G  Rp  such  that  ( Si  et-+i  S{+ 1)  |=  r. 

Def.  2.18  says  that  o  is  a  compliant  execution  of  Rp  if  all  its  state  transitions  comply  with  rules 
r  G  Rp .  Note  that  compliant  executions  can  terminate  abnormally  with  a,  failRemote  event,  or  can 
be  failure-free  -  if  it  does  not  terminate  with  a  failRemote . 

Definition  2.19  Compliant  executions  of  a  protocol 

Given  a  computation  o  :  so  e\  s\  . . .  for  a  system  of  processes  and  a  protocol  <  P,  /,  R,T  >,  o 
is  a  compliant  execution  of  the  protocol  if  and  only  if: 

L  so  f=  I;  and 

2.  Vp  G  P,  <r  |  p  is  a  compliant  execution  of  Rp. 

Def.  2.19  says  that  a  computation  is  a  compliant  execution  of  a  protocol  if  and  only  if  its  initial 
state  satisfies  the  initial  condition  of  the  protocol,  and  its  projections  (along  each  of  the  principals) 
are  compliant  execution  of  its  principals’  local  protocols. 

Definition  2.20  Abortive  executions  of  a  local  protocol 

Let  o  :  So  e\  s\  . .  .sn  be  a  computation  of  a  single  process  and  Rp  be  a  local  protocol  o  is  an 
abortive  execution  of  Rp  if  and  only  if 

so  t\  Si . . .  sn—i  is  a  compliant  execution  of  Rp  and  en  =  failLocal 

Definition  2.21  Deceptive  executions  of  a  local  protocol 

Let  o  :  so  e\  S\ . . .  be  a  computation  of  a  single  process  and  Rp  be  a  local  protocol  o  is  a 
deceptive  execution  of  Rp  if  and  only  if 
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a  is  not  a  compliant  execution  of  Rp  only  because  there  are  (s{  et*+1  s?+1)  E  o  such  that 
( Si  ct-+i  5i+i)  |=d  r  /or  a  rule  r  e  Rp. 

Def.  2.21  says  that  o  is  a  deceptive  execution  of  a  local  protocol  if  and  only  if  o  deviates  from  a 
compliant  execution  in  that  it  takes  deceptive  steps. 

Definition  2.22  Abortive  ( deceptive )  execution  of  a  protocol 

Let  a  :  s0  ei  si  ...  be  a  computation  of  a  system  and  <  P, /,  P,  T  >  be  a  protocol,  o  is  an 
abortive  ( deceptive )  execution  of  the  protocol  if  and  only  if: 

1.  s0  \=  I; 

2.  There  exists  at  least  one  p  E  P  such  that  a  |  p  is  an  abortive  ( deceptive  )  execution  of  Rp; 
and 

3.  For  the  remaining  principals  pl ,  o  |  p '  is  a  compliant  execution  of  Rp>. 

Def.  2.22  says  that  a  computation  is  an  abortive  (deceptive)  execution  of  a  protocol  if  its  initial 
state  satisfies  the  protocol’s  initial  condition,  and  at  least  one  of  its  projections  ~  along  each  of  the 
principals  -  is  an  abortive  (deceptive)  execution,  while  all  others  are  compliant  executions. 

According  to  our  definitions,  neither  the  abortion  nor  the  deception  mode  subsumes  the  other. 
Given  a  process,  its  set  of  compliant,  abortive,  and  deceptive  executions  are  mutually  disjoint.  This 
is  not  necessarily  so.  We  could  define  executions  where  one  process  aborts,  while  another  deceives, 
and  yet  another  complies  with  the  protocol,  for  example.  For  now,  we  will  work  with  the  current 
set  of  definitions,  for  simplicity. 

Definition  2.23  Maximal  execution  of  a  protocol 

Let  o  be  a  ( compliant /abortive /deceptive )  execution  of  a  protocol  II.  a  is  a  maximal 
( compliant /abortive /deceptive )  execution  of  II  if  and  only  if: 

there  does  not  exist  a  (compliant /abortive /deceptive)  execution  a'  of  II,  such  that  a  is 
a  proper  prefix  of  a'. 

Def.  2.23  says  that  a  is  a  maximal  execution  if  and  only  if  it  cannot  be  further  extended. 

Trustworthy  Executions 

In  what  follows,  |=*  denotes  the  standard  satisfaction  relation  defined  for  linear  time  temporal  logic 
formulas  [67]. 

Definition  2.24  Trustworthy  executions  of  a  protocol 

Let  a  be  a  (compliant /abortive/ deceptive)  execution  of  a  protocol  <  P,  /,  P,T  >,  where  T  = 
{T\) . . . ,  Tk},  and.  g\s  be  the  sequence  of  states  projected  from  g.  g  is  trustworthy  if  and  only  if: 

a\s\=*  A  A  r,  or  equivalently,  a  \  s  |=*  T. 

*€{l,...,fc}  reT, 

Def.  2.24  says  that  trustworthy  executions  are  those  whose  sequence  of  states  satisfy  all  the  trust 
assumptions  of  a  protocol. 
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2.4.3  p-Protective  Protocols 

In  this  subsection,  we  formally  define  p-protective  protocols.  Our  formalization  captures  the  follow¬ 
ing  insights.  First,  in  commerce  transactions,  different  parties  have  different  interests  to  preserve. 
Second,  electronic  commerce  protocols  should  be  designed  to  protect  their  user’s  interests  against 
communication  failures  and  both  intentional  and  unintentional  misbehaviors  of  other  users.  Lastly, 
trust  assumptions  should  be  taken  into  account  when  defining  p-protective  protocols:  often  they 
are  what  protocols  rely  on  to  achieve  p-protection. 

In  what  follows,  we  consider  three  deviation  modes:  C  (compliance),  A  (abortion),  and  D  (de¬ 
ception);  and  use  E^II)0,  E(U)A ,  and  E(U)D  to  denote  respectively  the  set  of  maximal  compliant, 
abortive  and  deceptive  executions  of  a  protocol  IT.  Also,  let  x  range  over  {C,  A,  D]  and  p  over  the 
set  of  principals  of  II,  then  we  use  E{Il)%  to  denote  the  set  of  maximal  x-executions  of  II  where  p’s 
projection  is  a  compliant  execution  of  Rp. 

Our  definitions  below  apply  only  to  protocols  whose  maximal  compliant  executions  are  trust¬ 
worthy.  This  is  an  expected  restriction:  if  trust  assumptions  specify  behaviors  that  trusted  parties 
should  exhibit  even  under  deviation  modes,  then  these  same  behaviors  should  be  exhibited  under 
the  compliance  mode  in  the  first  place. 

Definition  2.25  Let  II  =<  P,I,R,T  >  be  a  protocol,  p  €  P  be  a  principal,  Pp  be  p’s  protection 
property,  and  x  be  the  deviation  mode  we  consider.  II  protects  p ’s  interests,  under  x  deviation  mode, 
if  and  only  if 

1.  Va  €  E(U)c,o  \=*  Pp ;  and 

2.  Va  6  jF(II)p,  if  o  \=*  T  then  a  f=*  Pp. 

Definition  2.26  p-protective  protocols 

Let  II  =<  P,I,R,T  >  be  a  protocol,  p  e  P  be  a  principal,  Pp  be  p’s  protection  property,  and 
x  be  the  deviation  mode  we  consider.  II  is  p-protective  under  x  mode  if  and  only  if  II  protects  p’s 
interests  under  x  mode. 

Defs.  2.25  and  2.26  can  be  used  to  derive  the  definition  of  p-protective  protocols  under  different 
deviation  modes.  Under  C  mode,  E(U.)C  is  the  set  of  executions  one  needs  to  examine,  since 
E( n)c  U  E( U)p  =  E(E)C  and  all  executions  in  £,(II)C'  are  trustworthy3.  Under  A  and  D  modes, 
E( U)c  plus  trustworthy  executions  in  £(n)cU.E(n)^  and  E(U)C'JE{U)^  are  respectively  the  sets 
of  executions  that  need  to  be  examined.  Intuitively,  a  protocol  is  p-protective  under  compliance 
mode  if  and  only  if  for  all  compliant  executions  a,  a  satisfies  Pp;  II  is  p-protective  under  abortion 
(deception)  mode  if  and  only  if  for  all  compliant  executions  and  trustworthy  abortive  (deceptive) 
executions  a  where  p  behaves  compliantly,  a  satisfies  Pp. 

Example:  We  say  that  a  sale  protocol  is  customer-protective  under  abortion  mode  if  customer’s 
interests  are  protected  in  all  E(U)C  and  trustworthy  executions  in  E(U)fustomer. 

It  is  often  desirable,  though  not  necessary,  that  a  protocol  protects  the  interests  of  all  its 
participants  (or,  more  precisely,  of  those  that  have  interests  to  preserve).  We  call  protocols  that 
do  so  all-protective  protocols. 

3  Section  2.3.3  has  a  brief  justification  of  why  all  executions  in  f?(II)c  are  trustworthy. 
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Definition  2.27  All-protective  protocols 

Let  II  =<  -P,  /,  R,  T  >  6e  a  protocol;  P*  —  {pi , . . . ,  p/J  5e  £Ae  0/ principals  that  have  interests 
to  preserve;  Ppi ,  i  =  1, . . . ,  k,  be  respectively  pi ’s  protection  properties;  and  x  be  the  deviation  mode 
we  consider .  FI  is  all-protective  under  x  mode  if  and  only  if 

II  is  pi-protective,  under  x  mode,  for  all  pi  £  P' . 

Example:  We  say  that  a  sale  protocol  II  is  all-protective  under  deception  mode,  if  II  is  both 
customer-protective  and  merchant-protective  under  deception  mode. 

Definitions  2.25,  2.26,  and  2.27  give  a  general  and  abstract  framework  in  which  the  notion 
of  protection  is  formalized.  The  abstract  definitions  can  be  refined  by  instantiating  Pp s  with 
more  concrete  properties.  For  instance,  if  II  is  a  sale  protocol,  then  there  are  two  Pp  s  of  interest, 
namely,  Pc  (customer’s  protection  property)  and  PM  (merchant’s  protection  property),  which  have 
respectively  the  following  general  forms: 

Pc :  If  the  merchant  receives  the  payment,  then  the  customer  must  have  received  or  must 
eventually  receive  the  goods. 

Pm *  U  the  customer  receives  the  goods,  then  the  merchant  must  have  received  or  must 
eventually  receive  the  payment. 

If  II  is  a  withdrawal  protocol,  then  there  are  also  two  Pp’s  of  interest,  namely,  PB  (bank’s  protection 
property)  and  Pu  (user’s  protection  property). 

For  the  protocols  we  analyzed,  Pp  s  were  formaliza.ble  in  linear  time  temporal  logic,  which 
justifies  our  using  a  Pp  to  formalize  preservation  of  protection  property  Pv  by  execution  a. 

The  informal  characterizations  above  are  still  general  and  abstract.  When  investigating  a 
specific  protocol,  they  need  to  be  further  refined.  For  example,  receiving  payment  may  mean 
receiving  cash  in  one  protocol,  and  receiving  a  check  in  another.  In  other  words,  the  formalization 
of  protection  properties  requires  protocol- specific  information  and  cannot  be  made  concrete  until 
after  a  protocol  is  given. 

We  can  refine  the  informal  characterizations  above  in  a  second  dimension.  In  closed  characteri¬ 
zations  of  p-protection,  we  require  protection  properties  to  be  satisfied  at  the  end  of  protocol  runs. 
For  example,  “receiving  an  item”  is  “actually  receiving  an  item  during  a  protocol  run”.  In  open 
characterizations,  we  allow  protection  properties  to  be  -  temporarily  -  violated,  as  long  as  they  can 
be  restored  later.  In  this  case,  “receiving  an  item”  can  be  translated  into  “actually  receiving  an 
item  during  a  protocol  run”  or  “receiving  non-repudiable  evidence  of  entitlement  during  a  protocol 
run”,  so  that  one  can  use  it  later  in  court  to  reclaim  the  item. 


2.5  Assumptions  and  Their  Implications 

We  make  a  number  of  assumptions  in  our  model.  In  this  section,  we  discuss  their  implica¬ 
tions/limitations. 

In  our  model,  we  assume  that  each  agent  runs  one  process  at  a  time.  This  assumption  simplifies 
our  model,  but  prevents  us  from  uncovering  problems  (for  example  [63])  that  can  arise  only  when 
multiple  processes  run  concurrently. 
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We  assume  communication  security:  if  a  message  is  received,  then  it  is  received  by  the  intended 
recipient,  authenticated,  confidential,  and  untampered.  Effectively,  we  assume  that  the  processes 
we  consider  use  the  service  of  an  underlying  layer  of  security  protocols.  Layering  of  protocols  may 
lead  to  unexpected  interactions,  and  unless  we  can  assure  ourselves  that  no  undesirable  interactions 
exist,  our  conclusion  about  whether  a  protocol  is  all- protective  is  not  definitive.  Our  approach 
divides  the  task  of  analyzing  layered  protocols  into  two  subtasks:  we  first  analyze  individual  layers, 
and  then  the  interactions  between  the  layers.  In  this  dissertation,  we  focused  on  the  first  subtask. 

Perfect  encryption  is  another  assumption  we  make.  It  says,  in  its  most  basic  form,  that  the 
only  way  to  obtain  any  information  from  an  encrypted  message  is  to  have  the  right  decryption 
key.  In  our  work,  this  assumption  extends  to  other  cryptographic  primitives  (e.g.,  blinding  and 
unblinding)  as  well.  In  general,  however,  cryptographic  primitives  may  be  amenable  to  different 
types  of  analysis  (e.g.,  timing  and  probabilistic),  and  these  analysis  may  have  implications  at  the 
protocol  level.  Like  communication  security  assumption,  this  assumption  allows  us  to  decompose 
the  task  of  analyzing  protocols  into  subtasks:  in  this  case,  analysis  of  protocols  themselves,  assuming 
ideal  cryptography;  and  analysis  of  interactions  between  the  protocols  and  lower-level  properties 
of  cryptographic  primitives. 

In  our  specification  of  protocol  rules,  we  assume  that,  at  reception,  recipients  of  messages  only 
check  for  typing  of  messages  they  receive.  Rule  Rm$  (page  70)  in  NetBill,  for  example,  prescribes  M 
to  receive  only  messages  of  type  t.sepo.  We  made  this  assumption  because  it  offers  us  a  reasonable 
level  of  abstraction.  We  can  do  more  or  less  checks  at  reception,  however,  and  the  change  does 
not  bring  critical  consequences.  For  example,  under  deception  mode,  principals  currently  receive 
messages  first,  and  then  learn  that  they  are  bogus.  If  more  checks  are  conducted  at  reception,  one 
can  reject  receiving  bogus  messages  altogether.  This  difference  is  inconsequential  because  checks 
are  effectively  needed  only  right  before  certain  critical  steps,  and  it  does  not  matter  when  checks 
take  place,  as  long  as  they  occur  before  these  steps. 

Finally,  we  assume  that  protocol  executions  are  finite.  In  fact,  our  definition  of  p-protective 
protocols  takes  into  account  only  maximal  executions,  and  our  analysis  of  protocols  relies  on  the 
fact  that  all  compliant/abortive/deceptive  executions  of  a  protocol  are  finite.  Not  all  protocols 
have  finite  executions,  however.  For  example,  there  can  be  servers  that  can  respond  to  requests 
infinitely  often.  Our  framework  is  not  applicable  to  this  class  of  protocols. 
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Chapter  3 


Franklin  and 


Reiter’s  Protocol 


In  this  chapter,  we  present  our  first  case  study,  a  fair  exchange  protocol  [42]  proposed  by  Franklin 
and  Reiter.  We  specify  the  protocol  -  henceforth  referred  to  as  FR’s  protocol  —  in  our  proto¬ 
col  specification  formalism  (Section  2.3)  and  analyze  it  with  respect  to  protection  of  individuals’ 
interests  using  our  framework  (Section  2.4).  Since  we  are  interested  in  protection  of  all  parties 
equally,  we  analyze  it  with  respect  to  all-protection.  FR’s  protocol  differs  from  previous  work1 
([57,  58,  5,  28,  89,  31])  on  fair  exchange  in  that  it  uses  semi-trusted  third  parties  instead  of  fully- 
trusted.  ones. 

FR’s  protocol  is  the  simplest  among  the  three  we  analyze,  in  terms  of  both  the  protocol’s 
functionality  and  its  protection  properties.  Our  analysis  does  not  reveal  any  surprises:  the  protocol 
is  all-protective  under  all  three  deviation  modes,  as  long  as  communication  links  are  reliable. 

Our  main  contribution  in  this  case  study  is  a  formalization  of  semi-trusted  third  parties. 
Franklin  and  Reiter  introduce  the  notion  of  semi-trustworthiness  in  electronic  commerce  proto¬ 
cols  [42],  but  they  do  not  fully  develop  it.  In  particular,  they  do  not  take  it  into  account  in 
their  (informal)  analysis  of  the  protocol.  In  our  framework,  we  can  formalize  the  notions  of  semi¬ 
trustworthiness  and  conspiracy  behaviors  using  trust  assumptions,  and  provide  a  clear-cut  analysis 
of  the  protocol. 

The  rest  of  this  chapter  is  structured  as  follows.  In  Section  3.1,  we  introduce  the  protocol 
and  assumptions  made  by  its  designers,  and  justify  why  it  was  chosen  for  our  first  case  study.  In 
Section  3.2,  we  present  an  abstract  formulation  of  the  mathematical  building  blocks  used  in  it. 
In  Section  3.3,  we  formalize  both  the  protocol  and  the  protection  properties.  In  Section  3.4,  we 
show  the  main  results  and  their  analyses.  Detailed  proofs  are  reserved  for  Section  3.5.  Finally, 
in  Section  3.6,  we  summarize  the  findings  of  our  analysis  and  discuss  our  contributions  towards 
formalizing  semi-trustworthiness. 


3.1  Introduction 

3.1.1  Preliminaries 

FR’s  protocol  [42]  enables  two  parties  X  and  Y  to  exchange  documents  with  the  mediation  of 
a  third  party  Z.  It  was  designed  to  guarantee  “fair  exchange”,  i.e. ,  no  party  should  be  able  to 

1  We  have  not  included  here  earlier  work  on  “contract  signing”  [10,  11,  88,  65,  85,  27],  because  they  are  inefficient 
(not  practical)  and  not  applicable  to  electronic  commerce  protocols. 
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gain  any  advantage  by  quitting  prematurely  or  otherwise  misbehaving.  Franklin  and  Reiter  take 
fair  exchange  in  a  strict  sense:  a  party  engaged  in  an  exchange  should  not  be  able  to  trick  the 
other  into  accepting  a  document  different  from  the  one  that  is  expected.  This  view  differs  from 
that  of  NetBill  [84],  for  example.  In  NetBill,  it  is  possible  for  a  vendor  to  provide  an  arbitrary 
document  during  an  online  exchange.  The  protocol  only  enables  such  cheating  to  be  detected  after 
the  exchange  occurs,  using  mediation  outside  the  scope  of  the  protocol. 

FR’s  protocol  differs  from  previous  solutions  to  fair  exchange  in  that  it  assumes  semi-trusted  - 
instead  of  fully-trusted  -  third-parties.  In  Franklin  and  Reiter’s  definition,  a  third  party  is  fully- 
trusted  if  it  does  not  misbehave  at  all,  and  is  semi-trusted  if  it  misbehaves  on  its  own,  but  does 
not  conspire  with  either  of  the  main  parties. 

Franklin  and  Reiter  assume  a  model  in  which  documents  are  encrypted  under  a  key  and  en¬ 
crypted  documents  are  publicly  accessible.  To  get  a  document,  one  only  needs  to  get  the  decryption 
key  from  the  owner  of  the  document.  To  guarantee  that  the  owner  of  a  document  does  not  fool 
interested  parties  with  wrong  decryption  keys,  the  authors  assume  that  parties  in  the  system  have 
a  one-way  hash  /(A)  of  the  keys  K  they  desire.  During  an  exchange,  they  provide  these  hash 
values  to  the  intermediary,  who  uses  them  to  verify  whether  the  keys  supplied  by  document  owners 
are  the  expected  ones.  Through  this  mechanism,  exchanges  succeed  only  with  desired  keys. 

The  assumption  that  parties  know  one-way  hashes  of  keys  they  desire  holds  in  some  existing 
protocols  (e.g.,  [49,  77,  39,  48]).  Franklin  and  Reiter  assume  the  existence  of  a  public  database 
of  tuples,  each  consisting  of  a  description  of  the  contents  of  a  data  file  (e.g.,  the  title  of  a  movie); 
an  encryption  of  the  data  file  (e.g.,  the  movie)  under  a  secret  key  K  ;  a  one-way  hash  f(K)  of 
the  secret  key;  and  an  authority’s  signature  on  the  preceding  information,  which  serves  as  the 
authority’s  appraisal  that  the  decryption  of  the  encrypted  data  file  using  I<  will  indeed  produce 
the  described  item. 

For  these  hash  values  to  be  useful,  however,  there  cannot  be  a  key  K'  ^  K  such  that  f(K’)  = 
otherwise,  the  document  owner  can  simply  run  the  protocol  with  K' .  To  ensure  that  this 
does  not  happen,  /  is  required  to  be  a  collision-free  function.  Collision-freeness  is,  in  truth,  stronger 
than  what  is  strictly  necessary  [42].  We  adopt  it  here  for  simplicity. 

Some  mathematical  details  are  important  to  the  functioning  of  FR’s  protocol.  /  must  be  a 
function  from  G  to  G  (/  :  G  — f  G ),  where  G  is  a  algebraic  group.  Moreover,  /  must  have  the 
property  that  there  exists  a  computable  function  F  :  G  X  G  — >■  G  such  that  F(x,f(y))  =  f(xy). 
Franklin  and  Reiter  give  a  few  concrete  one-way  hash  functions  with  these  properties  [42], 

3.1.2  The  Protocol 

Fig.  3.1  shows  the  protocol  as  it  was  given  [42].  It  assumes  that  X  holds  a  decryption  key  Kx,  Y 
holds  a  decryption  key  I<y,  and  X  and  Y  are  interested  in  exchanging  Kx  and  Ky.  It  also  assumes 
that  both  X  and  Y  know  a  one-way  function  /  :  G  — >  G  on  the  key  space.  For  the  remainder 
of  this  chapter,  Kx  and  Ky  will  be  treated  abstractly;  that  is,  merely  seen  as  secrets,  instead  of 
decryption  keys. 

To  give  I<x  to  Y,  X  first  splits  I<x  into  two  shares.  One  of  the  shares  is  x,  a  member  of 
G  generated  at  random  by  X.  The  other  is  Kxx~l,  the  product  of  Kx  with  the  inverse  of  x 
(We  use  product  to  mean  the  group  operation  in  O').  X  then  sends  x  to  Y  (step  1).  Y  takes 
an  analogous  step  (step  2).  Once  X  has  received  y  from  Y,  X  sends  to  Z  (step  3)  the  other 
share  Kxx~l  of  its  secret,  the  hash  value  f(y)  of  y.  and  the  hash  value  f{Ky)  of  the  secret  I<y 
it  desires.  f(I<x )  is  also  provided  for  redundancy.  Y  takes  an  analogous  step  (step  4).  Once  Z 
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X 


1.  X-+Y  : 

2.  Y  ->X  :  y 

3.  A-+Y:  /(AT*) /(A',)  A>-x /(y) 

4.  Y  -t  Z  :  /(Ay)  f(Rx)  RyV  1  /(*) 

5.  Y  — A  :  Kyy  x 

6.  Y  — f  Y  :  AjX 


The  various  symbols  denote: 

x,  y  :  Randomly  generated  members  of  a  algebraic  group  G; 
Kx ,  Ky  :  X’s  and  Y’s  secrets,  respectively; 

/  :  a  one-way  function  from  G  to  G. 


Figure  3.1:  FR’s  protocol. 


has  received  messages  from  both  X  and  Y ,  Z  can  verify  the  correctness  of  A'x’s  splitting  using  the 
equality  Va  £  G,b  £  G,  F(a,  /(h))  =  /(ah).  In  this  case,  F{Kxx~l,  f(x))  should  be  equal  to 
The  correctness  of  Ky ’s  splitting  can  be  verified  analogously.  If  both  secrets  are  split  correctly, 
Z  forwards  I<yy~i  to  X  (step  5)  and  Kxx~l  to  Y  (step  6).  X  can  then  use  y  and  Kyy~l  to 
reconstitute  Ky\  and  analogously  with  Y.  If  either  secret  is  split  incorrectly,  no  forwarding  takes 
place. 

Franklin  and  Reiter  assume  reliable  and  secure  communication  networks. 

FR’s  protocol  has  a  number  of  extensions  [42].  In  this  dissertation  we  focus  on  the  basic 
protocol. 

3.1.3  Discussion 

FR’s  protocol  is  an  ideal  candidate  for  our  first  case  study  because  it  explores  the  notion  of  semi- 
trusted  third  parties.  A  semi-trusted  third  party,  according  to  Franklin  and  Reiter,  is  a  trusted 
party  that  may  misbehave  on  its  own,  but  does  not  “conspire”  with  either  of  the  main  parties. 
They  do  not  precisely  distinguish  “misbehaviors  of  one’s  own”  from  “conspiracy  misbehaviors”. 
Informally,  however,  they  intend  “misbehaviors  of  one’s  own”  to  mean  misbehaviors  that  do  not 
bring  advantages  to  one  of  the  main  parties,  and  “conspiracy  misbehaviors”  to  mean  those  that 
would.  Their  interpretation  of  conspiracy  is  non-standard  in  that  a  misbehaving  party  can  conspire 
with  an  honest  party  without  the  honest  party’s  consent.  They  call  this  type  of  conspiracy  “passive 
conspiracy” . 

After  the  initial  discussion,  the  notion  of  semi-trustworthiness  is  not  further  taken  into  account 
however.  For  example,  for  their  characterization  of  fair  exchange  protocols,  Franklin  and  Reiter 
define  two  types  of  parties:  honest  parties  are  those  that  follow  the  protocol,  and  misbehaving 
parties  are  those  that  do  not.  A  protocol  satisfies  fair  exchange  property  if  the  following  hold  at 
the  end  of  an  execution: 

1.  If  all  three  parties  are  honest,  then  X  learns  Iiy  and  Y  learns  Rx. 
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2.  If  X  and  Z  are  honest,  then  Y  learns  nothing  useful  about  Kx  unless  X  learns  Ky . 

3.  If  Y  and  Z  are  honest,  then  X  learns  nothing  useful  about  Ky  unless  Y  learns  Kx. 

4.  If  X  and  Y  are  honest,  then  Z  learns  nothing  useful  about  Kx  or  Ky. 

Franklin  and  Reiter’s  characterization  of  fair  exchange  protocols  has  a  number  of  weaknesses. 

First,  it  assumes  1-resilience,  i.e.,  at  most  one  of  X,  Y,  and  Z  misbehaves.  In  an  open  network  where 
one  is  likely  to  interact  with  strangers,  this  assumption  seems  too  limiting.  It  is  particularly  limiting 
in  their  protocol  because  they  advocate  using  random  members  of  the  network  as  intermediaries. 

Second,  it  does  not  model  semi-trustworthiness.  In  the  characterization  of  fair  exchange  pro¬ 
tocols  above,  Z  either  follows  the  protocol  or  can  misbehave  arbitrarily.  Note  that  the  notion  of 
a  semi-trusted  Z  that  can  misbehave  on  its  own,  but  not  conspire  with  either  of  the  main  par¬ 
ties  is  not  captured  in  this  characterization.  Arbitrarily-misbehaving  Zs  pose  special  challenges  to 
characterizations  of  fairness.  For  example,  if  Z  disrupts  the  exchange  in  a  way  that  X  learns  I<y 
without  Y  learning  Ax,  then  fairness  is  certainly  compromised.  Franklin  and  Reiter  do  realize  this 
problem;  according  to  them  “It  is  debatable  whether  protection  against  passive  conspiracies  should 
be  included  in  our  model”  [42], 

We  argue  that  these  weaknesses  can  be  eliminated  if  semi-trustworthiness  is  explicitly  modeled, 
and  Z  is  assumed  not  to  display  conspiracy  behaviors. 

Our  framework  enables  explicit  modeling  of  conspiracy  behaviors  and  semi-trustworthiness. 
Conspiracy  behaviors  can  be  modeled  as  behaviors  that  violate  trust  assumptions  and  semi-trusted 
parties  can  be  modeled  as  parties  that  do  not  exhibit  conspiracy  behaviors.  In  fact,  in  our  char¬ 
acterization  of  ^-protective  protocols,  we  prescribe  analyzing  protocols  under  the  assumption  that 
trusted  parties  can  misbehave,  but  cannot  violate  their  trust  assumptions.  By  restricting  the  type 
of  misbehaviors  trusted  parties  can  exhibit,  we  can  eliminate  the  assumption  that  only  one  party 
misbehaves  in  each  execution,  and  answer  Franklin  and  Reiter’s  of  question  of  whether  conspiracy 
behaviors  should  be  considered  in  the  model. 

3.2  Abstract  Formulation  of  the  Building  Blocks 

In  this  section,  we  present  an  abstract  formulation  of  the  mathematical  building  blocks  used  in 
FR’s  protocol. 

To  “split”  a  key  A  into  Ax”1  and  x,  we  first  generate  x  at  random,  then  mask  K  using  x.  We 
represent  Kx~l  abstractly  by 

ma$k(K ,  x), 

where  mask  corresponds  to  inverting  x,  then  forming  the  product  of  I<  with  the  inverse  of  x.  To 
retrieve  K  from  Ax"1,  we  apply  another  product  operation:  (Iix~l)x,  which  converts  to  I< .  This 
retrieval  is  abstractly  represented  by 

unmask(mask(K,  x),x)  ==  A', 

where  unmask  corresponds  to  the  product  operation  and  =  denotes  a  conversion.  Henceforth,  we 
call  x  a  masking  key ,  and  mask(A',  x)  a  masked  secret. 

We  represent  the  one-way  hash  function  /  abstractly  by  hash ,  and  the  auxiliary  function  F  by 
auxJiash.  Thus,  F(x,/(j/))  =  f(xy)  can  be  mapped  into 

aux -hash  (x,  hash  (y))  ==  hash  (unmask  (x,  y)). 
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1. 

X  : 

X 

2. 

Y  : 

y 

3. 

X  ^  Z: 

hash(Kx)  hash(Ky)  mask(Kx,x )  hash(y ) 

4. 

Y  ^Z: 

hash(Ky)  hash(Kx )  mask(Ky,y )  hash(x ) 

5. 

Z^X  : 

mask(Ky,y ) 

6. 

Z  y  : 

mask(Kx,  x) 

The  various  symbols  denote: 

x,  y  :  Randomly  generated  masking  keys; 
Kx,  Ky  :  A’s  and  Y’s  secrets,  respectively. 


Figure  3.2:  An  abstract  formulation  of  FR’s  protocol. 

Finally  we  use  an  abstract  type  t  to  represent  groups  G. 

In  what  follows,  we  list  the  functions  and  their  conversion  rules. 

Definition  3.1  Abstract  building  blocks 

1.  Secrets  have  type  t,  i.e .,  if  K  is  a  secret,  then  K  :  t; 

2.  Masking  keys  have  type  t,  i.e.,  if  x  is  a  masking  key,  then  x  :  t; 

3.  Functions: 

•  mask:  t  X  t  t; 

•  unmask:  t  xt  t; 

•  hash:  t  t ; 

•  auxJiash:  t  x  t  — >•  t; 

4 .  Conversion  rules: 

•  \/K  :  t,x  :  t,y  :  t,  unmask(mask(K ,  x),  y)  =  A,  if  and  only  if  x  =  y; 

•  \/x  :  t,y  :  t,  auxJiashfx,  hash{y))  =  hash(unmask(x ,  y)). 

Note  that  we  make  the  Perfect  Encryption  Assumption  [45,  12]  in  our  framework.  In  its  most  basic 
form,  this  assumptions  says  that  the  only  way  to  obtain  any  information  from  an  encrypted  message 
is  to  have  the  right  decryption  key.  The  conversion  rule  regarding  mask  and  unmask  specifies  that 
a  masked  secret  cannot  be  retrieved  unless  it  is  unmasked  by  the  masking  key. 

The  protocol  in  Fig.  3.1  can  now  be  represented  as  in  Fig.  3.2. 

3.3  Formalizing  the  Protocol  and  the  Protection  Properties 

In  this  section,  we  specify  FR’s  protocol  and  protection  properties  different  principals  want  to  have 
guaranteed. 
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3.3.1  Specification  of  the  Protocol 
Principals  of  the  Protocol 

V  =  {X,Y,Z} 

Initial  Conditions 

Let  kx  and  kv  be  respectively  X's  and  Y’s  secrets,  the  initial  condition 

I  :  hash  (/£,,)  =  px  A  hash  («;,,)  =  py  A  {kx,  py }  C  MSX  A  {ny,px}  C  MSY 

says  that  px  and  py  are  respectively  kx's  and  Ky' s  hashes;  principal  X  has  both  kx  and  py  in  its 
local  store;  and  principal  Y  has  Ky  and  px  in  its  local  store. 

Local  Protocols 

In  the  specification  below,  we  introduce  timeouts  in  some  select  places.  Intuitively,  they  are  intro¬ 
duced  in  points  where  a  send  or  a  receive  event  in  an  already  initiated  communication  is  expected. 
In  these  points,  timeouts  handle  communication  delays  and  disruptions.  If  a  send  or  a  receive  is 
critical,  however,  then  no  timeout  is  introduced  and  the  send  or  the  receive  is  allowed  to  take  place 
eventually. 

In  what  follows,  w,  x,  y  and  z  are  variables. 

X's  local  protocol  TZx  consists  of  the  following  rules: 

Rxt-  ft  x  :  t,  |  random}#)  £  H  =>  {random(y  :  f)} 

.Rx3:  3  x  :  t  |  random  (a:)  £  H  A  (/9  y  :  t  |  send(Y,  y)  £  H)  A  last(H)  ^  timeout  =$> 

{send  (Y,  x),  timeout} 

Rx2 :  {fix  :  t  |  receive(Y,  x)  £  H)  A  last(H)  ±  timeout  =*>  {receive(Y,  y  :  t)} 

Rx4'  (/3  y  :  t  |  receive(Y,  y)  €  H)  A  3  x  :  t  |  send(Y,  x)  £  H  A  last(H)  ^  timeout  => 

{receive(Y,  z  :  t),  timeout} 

Rxs:  3  y  :  t  |  receive(Y,  y)  £  H  A  3  x  :  t  |  send(Y,  x)  £  H  A 
( flz:txtxtxt  |  send(Z,  z)  £  H)  A  last(H)  timeout 

{send(^,  hash}*;*)  py  mask}**,  x)  hash(y)),  timeout} 

Rx6-  3x:txtxtxt  \  send(Z,  a;)£HA(/3y:t|  receive(Y,  y)  £  H)  A  last(H)  ^  timeout  ==> 

{  receive}  Y,  z  :t)} 

Rx7:  last(H)  =  timeout  V  3  x  :  t  |  last(H)  =  receive}/?,  x)  =>  {exit} 


Y’s  local  protocol  IZy  is  identical  to  IZxi  and  consists  of  the  following  rules: 
Ryi  •  x  :t  |  random}#)  £  H  =$■  {random(y  :  t)} 

Ry3i  3  y  :  t  |  random (y)  £  H  A  (fl  x  :  t  |  send(X,  x)  £  H)  A  last(H)  ±  timeout  =*► 
{send(X,  y),  timeout} 
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Ry2:  (fix  :  t  |  receive(X,  i)  6  H)  A  last(H)  fi  timeout  =>•  {receive(X,  y  :  f)} 

Ry4 :  (fix  :t  |  receive  (X,  x)  G  H)  A  3  y  :  t  |  send(X,  y)  G  H  A  last(H)  fi  timeout  =» 

{receive(X,  z  :  t),  timeout} 

Ry5 :  3  x  :  t  |  receive(X,  x)  G  H  A  3  y  :  t  |  send(X,  y)  G  H  A 

(fizitxtxtxt  I  send(X,  z)  G  H)  A  last(H)  fi  timeout  =*> 

{send(Z,  hash(Ky)  px  mask^,  y)  hash  (a:)),  timeout} 

RVe :  3x:txtxtxt\  send(X,  a;)  G  H  A  (fi  y  :  t  |  receive(X,  y)  G  H)  A  last(H)  fi  timeout  => 
{receive(X,  z  :  t)} 

Ry7:  last(H)  =  timeout  V  3  x  :  t  j  last(H)  =  receive(Z,  x)  =>•  {exit} 

Finally  X’ s  local  protocol  Rz  consists  of  the  following  rules: 

Rz2‘  ( fiy:txtxtxt  |  receive(F,  y)  G  H)  A  last(H)  fi  timeout  => 

{receive(F,  z\  t  xt  xt  xt),  timeout} 

Rzz:  (fix:txtxtxt  |  receive(X,  x)  G  H)  A  last(H)  fi  timeout 
{receive  (X,  w:  t  xt  Xt  xt),  timeout} 

Rz4 :  3  xi  x2  x3  x4  :  t  X  t  X  t  X  t  |  receive(X,  x\  x2  x3  x4)  G  H  A 
3  yi  «/2  2/3  2/4  :  t  x  t  x  t  x  t  |  receive(F,  yy  y2  yz  Va))  €  H  A 
xy  =  y2  =  aux_hash(x3,  y4)  A  yy  =  x2  =  aux_hash(y3,  x4)  A 
(fi  y  :t  |  send(X,  y)  G  H)  A  (fi  x  :  t  |  send(y,  x)  G  H)  A  last(H)  fi  timeout  =^> 

{send(X,  yz),  send(y,  a:3),  timeout} 

Rz5:  3  Xy  x2  x3  x4  :  t  X  t  X  t  X  t  |  receive(X,  Xy  x2  x3  x4)  G  H  A 
3  yi  V2  yz  Va  ■  t  x  t  x  t  x  t  I  receive  (y ,  yy  y2  yz  2/4)  €  H  A 

(Xy  =  y2  =  aux_hash(a:3,  y4)  A  yy  =  x2  =  aux_hash(y3,  x4))  {exit} 

Rz6:  3  xy  x2  x3  x4  :  t  X  t  X  t  X  t  \  receive(X,  x4  x2  x3  x4)  G  H  A 
3  t/i  J/2  2/3  Va  :  t  x  t  x  t  x  t  |  receive(y,  yy  y2  yz  2/4)  €  H  A 
3  y  :  t  |  send(X',y)  G  H  A  fi  x  :t\  send(y,  x)  €  H  =>  {send (y,  a?3) } 

Rzr :  3  2/1  J/2  yz  Va  ■  t  X  t  X  t  x  t  |  receive(y,  yy  y2  y3  y4)  €  H  A 
3  xy  x2  Xz  x4  :  t  x  t  x  t  X  t  I  receive(X,  Xy  x2  x3  x4)  G  H  A 
3  x  :  t  |  send(y,  x)  G  H  A  fi  y  :  t  |  send(X,i/)  fi  H  =>  {send(X,  y3)} 

Rzs:  last(H)  =  timeout  {exit} 

Rz9:  3  y  :  t  |  send(X,  y)  G  H  A  3  x  :  t  |  send(y,  a:)  G  H  =^>  {exit} 

Trust  Assumptions 

X  and  y  are  not  trusted  parties.  Thus,  Tx  =  true  and  7y  =  true.  Z  is  a  trusted  party.  It  is 

trusted: 

•  Tzy-  To  send  X’s  masked  secret  to  Y  only  if  y’s  secret  is  correctly  shared  by  X  and  Z; 
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•  Tz2:  To  send  Y’s  masked  secret  to  Y  only  if  Y’s  secret  is  correctly  shared  by  Y  and  Z;  and 

•  Tz3 :  To  forward  both  Y’s  masked  secret  to  Y  and  Y’s  masked  secret  to  X,  or  neither. 

These  trust  assumptions  can  be  formalized  as  follows. 

TZj:  □  (3  xi  x2  x3  x4  :  t  x  t  x  t  x  t  \  receive(Y,  x4  x2  x3  x4)  G  H  A  send(Y,  x3)  6  H  -> 

(3  2/i  y2  ?/3  «/4  •  t  X  t  x  t  X  t  |  receive(Y ,  y4  y2  y3  y4)  G  H  A  yi  =  x2  =  aux_hash(j/3,  2:4))) 

Tz2:  □  (3  yx  y2  y3  y4  :  t  xt  xt  xt  \  receive(Y,  y1  y2  y3  y4)  6  H  A  send(X,  i3)€H4 

(3  x4  x2  x3  x4  :  t  x  t  x  t  x  t  |  receive(X,  X\  x2  x3  x4)  €  H  A  y\  =  x2  =  aux_hash(?/3,  £4))) 

TZa:  □  (3  x1  x2  x3  x4  :  t  x  t  x  t  x  t  \  (receive^,  xx  x2  x3  x4)  G  H  A  send(Y,  x3)  G  H)  -4 

((3  J/i  2/2  2/3  2/4  :  t  X  f  X  t  X  t  |  (receive(Y,  r/x  y2  Vz  y4)  6  H  A  send(X,  y3)  G  H))  V 

(fail Remote  G  H  A  :  t  \  send(X,y)  G  H)))  A 
D  (3  y\  V2  2/3  V4  ■  t  X  t  X  f  X  t  I  (receive(Y ,  yj  y2  y3  y4)  G  H  A  send(X,  y3)  G  H)  -4 

O  ((3  a?x  a;2  a:3  x4  :  t  x  t  x  t  X  t  \  (receive^,  x4  x2  x3  x4)  G  H  A  send(Y,  x3)  G  H))  V 
(fail Remote  G  H  A  fix  :  t  \  send(Y,a;)  G  H))) 

TZi  says  that,  at  any  state  of  an  execution,  if  Z  sends  X’s  masked  secret  -  x3  -  to  Y,  then  Y’s 
secret  is  correctly  shared  by  X  and  Z  -  expressed  in  our  formalization  by  the  equality  y1  —  x2  = 
aux_hash(y3,  x4).  Tz2  is  symmetric  to  TZl .  TZs  says  that  if  Y’s  masked  secret  -  x3  -  is  sent  to 
Y,  then  eventually  Y’s  masked  secret  —  y3  —  would  have  been  sent  to  X ,  unless  a  communication 
failure  prevents  Z  from  sending  the  second  message;  and  symmetrically.  Note  that  y3  could  have 
been  sent  before  or  after  x3  has  been  sent. 

3.3.2  Specification  of  Protection  Properties 

In  the  context  of  FR’s  protocol,  Y’s  protection  property  says  that 
“If  Y  gets  Y’s  secret,  then  Y  gets  Y’s  secret”, 
while  Y’s  says  that 

“If  Y  gets  Y’s  secret,  then  Y  gets  Y’s  secret”. 

These  properties  can  be  respectively  formalized  as  Px  and  Py  below: 

Px  ■  □  (<^>1  — >  O  (f>2 ) 

Py  :  □  (<^2  -4  O  fa), 


where 


<t>i  -  3x  :  t,  z  :  t  |  receive(Y,  x)  G  HY  A  receive(Z,  z)  G  HY  A  unmask(z,  x)  =  kx, 
<t>2  =  3y  :  t,  z  :  t  \  receive(Y,  y)  G  Hx  A  receive(Y,  z)  G  Hx  A  unmask(2,  y)  =  ny. 
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3.4  Analysis  of  the  Protocol 

In  this  section,  we  analyze  FR’s  protocol  under  all  three  deviation  modes  defined  in  Section  2.4.3. 
Subsections  3.4.2,  3.4.3,  and  3.4.4  have  respectively  analyses  of  the  protocol  under  compliance, 
abortion  and  deception  modes.  Subsection  3.4.1  has  some  preliminary  theorems  and  lemmas. 

In  this  section,  we  present  only  the  main  results  with  their  high-level  analysis.  For  completeness, 
detailed  proofs  appear  in  Section  3.5. 

In  what  follows,  we  use  she,  he,  and  it  to  refer  to  X ,  Y ,  and  Z  respectively. 

3.4.1  Preliminaries 

In  this  subsection,  we  present  two  results  needed  in  the  rest  of  the  analysis.  Lemma  3.2  says 
that  each  protocol  step  gets  instantiated  at  most  once  in  executions  we  consider.  Its  proof  is 
straightforward,  and  depends  on  the  fact  that  the  enabling  condition  of  all  the  protocol  rules  check 
for  prior  occurrences  of  the  types  of  events  they  prescribe. 

Lemma  3.2  Let  II  be  FR’s  protocol,  o  be  an  execution  in  £,(II)c'u£'(n)j4UF(II)D,  et  be  an  event 
in  o,  and  E  be  an  event-template  prescribing  a  protocol  step  in  II.  If  e,-  is  an  instance  of  E,  then 
there  does  not  exist  ej  in  o ,  i  j ,  such  that  ej  is  also  an  instance  of  E. 

The  following  three  lemmas  are  needed  in  Theorem  3.6. 

Lemma  3.3  Let  II  be  FR’s  protocol  and  Tz  =  {TZl,Tz2,Tz3}  be  the  trust  assumptions  we  make 
of  Z  (as  given  in  Section  3.3.1).  Then 

VoeE{Il)c,  o\=*TZl. 

Lemma  3.4  Let  II  and  Tz  =  {Tzj,  Tz2,  TZz)  be  as  specified  in  Lemma.  3.3.  Then 

Vo  €  E{U)C,  o  \=*  Tz2. 

Lemma  3.5  Let  II  and  Tz  -  {TZl,Tz2,Tz3}  be  as  specified  in  Lemma.  3.3.  Then 

Vo  6  E{U)C ,  a  K  TZs. 

Theorem  3.6  says  that  all  maximal  compliant  executions  of  FR’s  protocol  are  trustworthy. 

Theorem  3.6  Let  II  be  Franklin  and  Reiter’  protocol  and  T  be  its  trust  assumptions.  Then 

Vo  €  E{H)C,  a  |=*  r. 

Proof:  Given  that  Z  is  the  only  trusted  party,  T  —  Tz  =  {TZl ,  Tz2,Tz3},  and  this  theorem  follows 
from  Lemmas  3.3,  3.4,  and  3.5. 

□ 
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3.4.2  Protection  Under  Compliance  Mode 

In  this  subsection,  we  analyze  the  protocol  under  the  assumption  that  all  principals  behave  as 
prescribed  by  the  protocol,  deviating  from  it  only  if  communication  channels  fail. 

To  verify  whether  the  protocol  is  all-protective,  we  need  to  verify  whether  it  is  both  A-protective 
and  Y-protective.  We  start  with  A"-protection. 

Proposition  3.7  Let  II  be  FR’s  protocol '  a  be  an  execution  in  E(Tl)c ,  and  Px  be  X’s  protection 
property  as  specified  in  Section  3.3.2 .  Then 


*  K  Px- 


Analysis: 

1.  Let  S{  be  a  state  such  that  Y  has  received  a  message  mi  from  X  and  a  message  m2  from  Z, 
and  mi  and  m2  are  such  that  unmask(m2,  mi)  =  nx. 

Then,  at  X  must  have  received  a  message  m[  from  Y;  and  eventually,  either  Z  will  have 
sent  a  message  m2  to  A,  or  Z  will  have  failed  to  do  so  because  of  a  communication  channel 
failure. 

2.  We  have  two  scenarios  to  consider: 

(a)  If  the  communication  channel  between  X  and  Z  does  not  fail,  then,  at  the  end  of  the 
execution,  Z  will  have  sent  m2  to  X  and  X  will  have  received  it.  Since  m2  was  received 
from  Y  and  Y  behaves  compliantly,  unmask(m'2,  m[)  =  ny,  and  X  will  have  been  able 
to  reconstitute  ny. 

(b)  If  the  communication  channel  between  X  and  Z  fails,  then  Z  will  not  have  been  able 
to  send  m2  to  A,  or  m2  will  have  been  sent  but  not  have  been  received  by  A.  In  either 
case,  X  does  not  receive  the  second  share  of  kv. 


□ 

The  analysis  of  Proposition  3.7  shows  that  protection  of  A’s  interest  relies  critically  on  1)  A’s 
receiving  a  message  from  Z,  and  2)  the  message  X  receives  from  Y  and  the  message  she  receives 
from  Z  form  a  correct  splitting  of  Y’s  secret  Ky.  If  the  communication  channel  between  X  and  Z 
does  not  fail,  then  X  receives  the  message  Z  forwards  -  which  will  allow  her  to  reconstitute  ny, 
and  her  interest  is  protected.  Otherwise,  either  Z  is  prevented  from  sending  the  message  or  X  does 
not  receive  it.  In  either  case,  her  interest  is  violated. 

From  Prop.  3.7  we  can  derive  the  following 

Corollary  3.8  FR’s  protocol  is  X -protective  under  compliance  mode  if  the  communication  channel 
between  X  and  Z  does  not  fail. 

Proposition  3.9  addresses  Y-protection. 

Proposition  3.9  Let  II  be  FR’s  protocol,  a  be  an  execution  in  E(U)C,  and  Py  be  Y ’s  protection 
property  as  specified  in  Section  3.3.2.  Then 


°\=*  Py* 
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Analysis:  analogous  to  that  of  Proposition  3.7,  given  that  Y’s  local  protocol  and  protection 
property  are  analogous  to  A’s. 

□ 


Corollary  3.10  follows  from  Prop.  3.9. 

Corollary  3.10  FR’s  protocol  is  Y -protective  under  compliance  mode  if  the  communication  chan¬ 
nel  between  Y  and  Z  does  not  fail. 

Theorem  3.11  summarizes  the  results  in  this  subsection: 

Theorem  3.11  Under  the  assumption  that  all  principals  behave  compliantly,  Franklin  and  Reiter’s 
protocol  is  all-protective  if  communication  channels  between  X  and  Z,  and  Y  and  Z  do  not  fail. 

Proof:  From  Corollaries  3.8,  and  3.10. 

□ 


Discussion 

In  FR’s  protocol,  secrets  are  not  released  as  a  whole.  Take  A’s  secret  Kx  for  example.  It  is  “split” 
into  two  shares  by  X.  One  of  the  shares  is  given  to  Y  and  the  other  given  to  Z.  Y  would  be  able 
to  reconstitute  kx  later,  if  Z  forwards  its  share  to  Y. 

If  Y  is  able  to  reconstitute  Kx  from  messages  mi  and  m2  he  receives  respectively  from  X  and 
Z,  then  Z  must  have  received  messages  from  both  X  and  Y,  and  must  have  been  able  to  verify 
the  correctness  of  both  secret  splittings.  Since  a  compliant  Z  sends  a  message  to  Y  if  and  only  if 
it  sends  a  message  to  X,  it  will  try  to  forward  its  share  of  Y’s  secret  Ky  to  X,  which  can  then  be 
used  by  X  to  reconstitute  Ky. 

The  problem  arises  if  the  communication  channel  between  X  and  Z  is  unreliable:  Z  may  be 
prevented  from  sending  the  message  to  A,  or  the  message  it  sends  may  never  be  received  by  X.  In 
either  case,  X  will  not  be  able  to  reconstitute  Ky. 

This  is  a  weakness  of  the  protocol,  particularly  because  Franklin  and  Reiter  advocate  Z  to  be  a 
“stranger”  -  a  random  party  from  the  network.  Strangers  on  the  net  can  come  and  go,  and  nothing 
in  the  protocol  guarantees  that  Z  can  be  contacted  later,  if  X  does  not  receive  a  message  from  it 
in  a  timely  manner.  X  can  try  to  contact  Y  to  get  the  missing  share.  But  Y  may  not  be  reachable 
himself.  Even  if  he  is,  Y  may  not  bother  to  cooperate  and  re-send  the  share  X  wants.  After  all, 
this  protocol  is  used  because  X  and  Y  do  not  trust  each  other. 

3.4.3  Protection  Under  Abortion  Mode 

In  this  subsection,  we  analyze  the  protocol  under  abortion  mode.  Like  with  compliance  mode,  we 
verify  whether  the  protocol  is  both  A-protective  and  Y-protective.  We  start  with  A-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  to  verify  whether  II  protects  A’s  interest 
under  abortion  mode,  we  need  to  examine  all  executions  in  E(J[)C  and  trustworthy  executions  in 
E(II)^.  Here  we  focus  on  abortive  executions  only,  since  we  have  analyzed  compliant  executions 
in  Section  3.4.2. 
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Proposition  3.12  Let  n  be  FR’s  protocol,  o  be  an  execution  in  E( U)x,  T  be  the  trust  assumptions 
If  makes ,  and  Px  be  X ’s  protection  property  as  specified  in  Section  3.3,2.  Then 

o  f=*  T  implies  a  f=*  Px . 

Analysis:  This  analysis  is  identical  to  the  one  for  Prop.  3.7,  except  for  what  is  in  italics  below. 

1.  Let  ${  be  a  state  such  that  Y  has  received  a  message  mi  from  X  and  a  message  m2  from  Z, 
and  mi  and  m2  are  such  that  unmask(m2,  mi)  =  kx. 

Then,  at  s;,  X  must  have  received  a  message  m[  from  Y;  and  eventually,  either  Z  will  have 
sent  a  message  m2  to  A,  or  Z  will  have  failed  to  do  so  because  of  a  communication  channel 
failure. 

Note  that  since  a  is  a  trustworthy  execution ,  Z  could  not  have  failed  to  send  m2  to  X  because 
of  local  problems  -  that  would  have  violated  the  trust  assumption  Tz3 . 

2.  We  have  two  scenarios  to  consider: 

(a)  If  the  communication  channel  between  X  and  Z  does  not  fail,  then,  at  the  end  of  the 
execution,  Z  will  have  sent  m2  to  X  and  X  will  have  received  it.  Since  neither  Z  nor  Y 
deceives,  unmask^,  m[)  =  ny,  and  X  will  be  able  to  reconstitute  ny. 

(b)  If  the  communication  channel  between  X  and  Z  fails,  then  Z  will  not  be  able  to  send 
m2  to  X  ,  or  mf2  was  sent  but  not  received  by  X  .  In  either  case,  X  does  not  receive  the 
second  share  of  ny. 


□ 

Jointly,  Props  3.7  and  3.12  address  A-protection  under  abortion  mode.  They  show  that  this 
protocol  offers  the  same  level  of  protection  to  A’s  interests  in  both  compliance  and  abortion  modes. 
Possible  failures  in  the  channel  linking  A  and  Z  are  still  what  can  compromise  A’s  interest. 

From  Prop.  3.7  and  3.12  we  can  derive  the  following 

Corollary  3.13  FR’s  protocol  is  X -protective  under  abortion  mode  if  the  communication  channel 
between  X  and  Z  does  not  fail. 

Proposition  3.14  addresses  protection  of  Y’s  interests  in  abortive  executions. 

Proposition  3.14  Let  II  be  FR’s  protocol,  a  be  an  execution  in  E(Jl)y,  P  be  the  trust  assumptions 
II  makes,  and  Py  be  Y ’s  protection  property  as  specified  in  Section  3.3.2 .  Then 

o  f=*  T  implies  a  f=*  Py. 

Analysis:  analogous  to  that  of  Proposition  3.12,  given  that  Y’s  local  protocol  and  protection 
property  are  analogous  to  A’s,  and  Tzz  is  equally  applicable  here. 


□ 

Jointly,  Props  3.9  and  3.14  address  y-protection  under  abortion  mode  (Corollary  3.15).  Here 
too,  possible  failures  in  the  channel  linking  Y  and  Z  are  still  what  can  compromise  Y’s  interest. 
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receive{X,f(I<x)  f{I<y )  Kxx~l  f(y))  receive(Y,  f(I<y)  f(I<x )  Kyy~l  /(as)) 

receive(Y,  f(Ky)  f(I<x )  Kyy~l  f(x ))  or  receive(X,  f(I<x)  f(I<y )  Kxx~l  /(y)) 
failLocal  failLocal 


Figure  3.3:  Examples  of  trustworthy  abortive  executions  of  Z. 


receive(X,f(Kx)  f(Ky )  I<xx  1  /(y)) 
receive(Y,  f(I<y)  f(Kx )  Aj,y_1  /(a:)) 
send{Y,Kxx~l) 
failLocal 


receive(YJ{Ky)  f(I<x)  Kyy~l  f{x)) 
receive(X,  f(Kx)  f(I<y )  Kxx~x  f(y)) 
send(X ,  A^y”1) 
failLocal 


Figure  3.4:  Examples  of  untrustworthy  abortive  executions  of  Z . 


Corollary  3.15  FR’s  protocol  is  Y -protective  under  abortion  mode  if  the  communication  channel 
between  Y  and  Z  does  not  fail 

Theorem  3.16  summarizes  the  results  in  this  subsection: 

Theorem  3.16  Under  abortion  mode ,  Franklin  and  Reiter’s  protocol  is  all-protective  if  communi¬ 
cation  channels  between  X  and  Z,  and  Y  and  Z  do  not  fail 

Proof:  From  Corollaries  3.13,  and  3.15. 

□ 


Discussion 

According  to  our  analysis,  the  ability  of  the  protocol  to  guarantee  all-protection  is  not  affected 
under  abortion  mode;  the  problem  still  lies  on  possible  channel  failures  between  Z  and  the  other 
two  principals.  This  seems  counter-intuitive,  since  depending  on  when  Z  terminates  its  execution, 
all-protection  can  actually  be  compromised.  For  instance,  if  Z  terminates  its  execution  right  after 
receiving  messages  from  both  X  and  Y ,  that  is,  Z’s  local  execution  is  as  shown  in  Fig.  3.3,  neither 
X-protection  nor  Y-protection  is  compromised,  since  neither  of  them  received  the  second  share  of 
the  secret  they  desire.  However,  if  Z  terminates  its  execution  after  sending  its  share  of  X's  secret 
( Kxx~l )  to  Y,  but  before  sending  its  share  of  Y’s  secret  (A^y”1)  to  X,  that  is,  if  Z’s  local  execution 
is  as  shown  in  Fig.  3.4,  then  X-protection  could2  be  violated,  since  X  would  never  receive  the  other 
share  of  Y’s  secret  from  Z. 

This  argument  overlooked  one  key  point:  the  executions  in  Fig.  3.4  do  not  belong  to  the  set  of 
executions  we  consider  in  this  analysis,  because  they  violate  the  trust  assumption  T^3. 

This  discussion  shows  how  trust  assumptions  limit  the  set  of  executions  we  consider  when 
analyzing  a  protocol  and  how  critical  they  are  in  our  conclusion  of  whether  or  not  a  protocol  is 
all-protective. 

2 We  use  could ,  instead  of  would ,  because  the  message  Z  sent  to  Y  might  never  get  to  Y  as  well.  This  could  happen 
due  to  Y’s  terminating  prematurely  for  example. 
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Y’s  deviations  do  not  affect  ^-protection;  the  readers  should  be  able  to  convince  themselves 
straightforwardly. 

3.4.4  Protection  Under  Deception  Mode 

In  this  subsection,  we  analyze  the  protocol  under  deception  mode. 

We  first  analyze  the  protocol  with  respect  to  A-protection,  then  with  respect  to  Y-protection. 
According  to  Def.  2.25  in  Section  2.4,  to  analyze  the  protocol  with  respect  to  A-protection,  we 
need  to  analyze  all  executions  in  E(U)C  and  trustworthy  executions  in  £(n)^.  Here  we  focus  on 
deceptive  executions  only,  since  we  have  analyzed  compliant  executions  in  Section  3.4.2. 

Proposition  3.17  Let  n  be  FR’s  protocol,  a  be  an  execution  in  E(Jl )%,  T  be  the  trust  assumptions 
n  makes,  and  Px  be  X  \ s  protection  property  as  specified  in  Section  3.3.2 .  Then 

a  J=*  T  implies  a  |=*  Px. 

Analysis:  This  analysis  is  very  similar  to  that  for  Prop.  3.7,  except  for  some  minor  details. 

1.  Let  Si  be  a  state  such  that  Y  has  received  a  message  m\  from  X  and  a  message  ra2  from  Z , 
and  mi  and  m2  are  such  that  unmask(ra2,  ?ni)  —  kx. 

Then,  at  the  same  state  Si ,  X  must  have  received  a  message  m\  from  Y;  and  eventually, 
either  Z  will  send  a  message  ra2  to  X ,  or  Z  will  fail  to  do  so  because  of  a  communication 
channel  failure. 

2.  We  have  two  scenarios  to  consider: 

(a)  If  the  communication  channel  between  X  and  Z  does  not  fail,  then,  at  the  end  of  the 
execution,  Z  will  have  sent  m'2  to  X  and  X  will  have  received  it.  Since  Z  behaves  as 
trusted,  ra2  is  the  message  A^  expects,  that  is  unmask(m2,  m[)  =  ny,  and  X  will  have 
been  able  to  reconstitute  Ky. 

(b)  If  the  communication  channel  between  X  and  Z  fails,  then  A  will  not  have  been  able 
to  send  m2  to  A,  or  m2  will  have  been  sent  but  not  have  been  received  by  X.  In  either 
case,  A  does  not  receive  the  second  share  of  ny. 


□ 

Analogous  to  the  analysis  of  Proposition  3.7  (regarding  compliance  mode),  the  analysis  of 
Proposition  3.17  shows  that  protection  of  A’s  interests  relies  critically  on  1)  A  receiving  a  message 
from  Z ,  and  2)  the  message  A  receives  from  Y  and  the  message  it  receives  from  Z  forming  a  correct 
splitting  of  Y’s  secret.  Analogous  to  the  compliance  mode  scenario,  if  the  communication  channel 
between  A  and  Z  does  not  fail,  then  X  receives  the  message  Z  sends.  Under  deception  mode, 
however,  this  message  may  not  be  the  one  that  would  allow  A  to  reconstitute  Y’s  secret,  unless  Z 
behaves  as  trusted.  If  Z  behaves  as  trusted,  then  Z  will  make  sure  that  the  message  it  forwards 
to  A  is  the  expected  one.  If  the  communication  channel  between  A  and  Z  fails,  and  either  Z  is 
prevented  from  sending  the  message  or  A  does  not  receive  the  message  sent  by  Z,  then  A’s  interest 
is  inevitably  compromised. 

Jointly  Props  3.7  and  3.17  address  A-protection  under  deception  mode  (Corollary  3.18).  They 
show  that,  like  in  the  other  two  modes,  this  protocol  is  A-protective  only  if  the  communication 
channel  between  A  and  Z  does  not  fail. 
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Corollary  3.18  FR’s  protocol  is  X -protective  under  deception  mode  if  the  communication  channel 
between  X  and  Z  does  not  fail. 

Proposition  3.19  addresses  protection  of  Y’s  interest  in  deceptive  executions. 

Proposition  3.19  Let  n  be  FR ’s  protocol,  o  be  an  execution  in  E(U)y,  T  be  the  trust  assumptions 
II  makes,  and  Py  be  Y ’s  protection  property  as  specified  in  Section  3.3.2.  Then 

a  |=*  T  implies  o  |=*  Py. 

Analysis:  analogous  to  that  of  Proposition  3.17,  since  Y’s  local  protocol  and  protection  property 
are  analogous  to  X’s,  and  assumption  T'z?j  is  equally  applicable  here. 

□ 

Jointly,  Props  3.9  and  3.19  address  Y-protection  under  deception  mode  (Corollary  3.20).  Pos¬ 
sible  failures  in  the  channel  linking  Y  and  Z  are  still  what  prevents  the  protocol  from  being 
Y-protective. 

Corollary  3.20  FR’s  protocol  is  Y-protective  under  deception  mode  if  the  communication  channel 
between  Y  and  Z  does  not  fail. 

Theorem  3.21  summarizes  the  results  in  this  subsection. 

Theorem  3.21  Under  deception  mode,  Franklin  and  Reiter’s  protocol  is  all-protective  if  commu¬ 
nication  channels  between  X  and  Z,  and  Y  and  Z  do  not  fail. 

Proof:  From  Corollaries  3.18,  and  3.20. 

□ 


Discussion 

In  this  subsection,  we  focus  on  what  happens  under  deception  mode.  Like  in  sections  3.4.2  and  3.4.3, 
we  focus  on  X-protection. 

According  to  our  proofs,  the  fact  that  Y  and  Z  may  send  out  arbitrary  messages  does  not 
affect  the  ability  of  the  protocol  to  guarantee  X- protection  (all  we  discussed  in  section  3.4.2  is 
still  applicable  here);  the  problem  still  lies  on  possible  channel  failures  between  X  and  Z.  It  is 
straightforward  to  see  that  Y’s  sending  arbitrary  messages  alone  cannot  compromise  X-protection, 
since  in  a  compliant  execution  of  Z,  Z  does  not  forward  Kxx~ 1  to  Y ,  unless  Z  has  made  sure  that 
jointly  X  and  Z  have  a  correct  splitting  of  Ky. 

But  what  if  Z  also  misbehaves?  For  example,  assume  that  Z  has  just  received  messages  from 
both  X  and  Y,  i.e.,  Z  has  just  experienced  the  following  events: 

receive(X,f(Kx )  f{I<y)  Kxx_1  f(y)) 
receive(Y,  f(Ky)  f{I<x)  I<yy~x  /(«)). 

Then  Rz 4  is  applicable,  which  means  that  Z  can  send  Kxx~l  to  Y,  Kyy~1  to  X,  or  timeout  next. 
In  a  scenario  where  Z  can  deceive,  Z  can  send  something  other  than  KyP-1  to  X.  Fig.  3.5  shows 
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receive{XJ{I<x)  f(Ky)  Kxx~l  f{y)) 
receive(YJ(Ky)  f{I<x )  Kyy-1  f(x)) 
send(X ,  Kxx~l) 
send(Y ,  A^a:-1) 
exit 


Figure  3.5:  An  untrustworthy  deceptive  local  execution  of  Z. 


receive(X ,  f(I<x)  f(I<y)  Kxx~l  f(y)) 

received,  f(Ky)  f(I<x)  Kyy~ 1  /(*)) 

send{X,Kxx~l) 

send(Y,  Kyy~1) 

exit 


Figure  3.6:  A  trustworthy  deceptive  local  execution  of  Z. 


an  example.  Under  this  scenario,  X-protection  is  clearly  violated,  since  what  X  receives  from  Z 
cannot  be  used  to  re-constitute  Ky. 

Here  is  where  trust  assumptions  come  to  the  rescue:  the  execution  in  Fig.  3.5  violates  Tz3,  and 
should  not  be  considered  when  analyzing  X-protection. 

Note  that  Z  can  deceive  without  violating  the  trust  assumptions  we  make  of  it.  The  execution 
in  Fig.  3.6  is  an  example. 

These  examples  illustrate  that  X-protection  is  not  compromised  whenever  Z  deceives;  but  it 
could  be  if  Z  violates  the  trust  assumptions.  We  use  could  instead  of  would  because  even  when  Z 
violates  the  trust  assumptions,  X-protection  might  not  be  violated.  In  Fig.  3.5,  for  example,  it  is 
violated  if  the  communication  channel  between  Y  and  Z  is  reliable  and  Y  receives  Kxx~l .  It  is  not 
violated,  however,  if  the  communication  channel  between  Y  and  Z  fails,  and  Y  does  not  receive 
Kxx-\ 


3.5  Formal  Analysis  of  the  Protocol 

This  section  contains  detailed  proofs  of  the  results  presented  in  Section  3.4.  These  proofs  use 
standard  proof  methods  and  are  presented  here  for  completeness. 

3.5.1  Preliminaries 

Lemma  3.4  Let  n  be  FR’s  protocol  and  Tz  =  {Tz1,Tz2,Tz3}  be  the  trust  assumptions  we  make 
of  Z  (as  given  in  Section  3. 3.1).  Then 

VoeE(nf,  o\=*TZl. 


Proof: 
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1.  Let  Si  be  a  state  in  a  and  aj  0,3  a4:  t  x  t  x  t  X  t  be  a  message  such  that 

S{  f=  receive  (A,  aj  02  «3  <4)  G  Hz  A  send(y,  a$)  G  Hz. 

Then  there  exists  a  state  Sk,  k  <  i,  such  that 

Sk  |=  receive(A,  ai  a2  03  a4)  €  Hz  A  last(Hz)  =  send(F,  03). 

We  know  that  such  a  state  exists  because,  according  to  Z: s  local  protocol,  Z  receives  from 
both  X  and  Y  first,  before  it  sends  messages  to  X  or  Y . 

At  Sk-,  the  last  rule  applied  by  Z  must  have  been  Rz4  or  Rz6- 

2.  If  sf  resulted  from  an  application  of  Rz4 ,  then  we  know  that  3j  <  k,  and  b\  b2  63  txtxtxt 
such  that 

sj  \=  receive  (F,  61  b2  63  64)  €  Hz  A  61  =  a2  =  aux_hash(63,  a4). 

3.  If  si  resulted  from  an  application  of  Rz6i  then  3 j  <  k,b'3  :  t  such  that 

Sj  |=  last(Hz)  =  send  (A,  63) , 

which  could  have  resulted  only  from  an  application  of  Rz4  ■  To  be  applicable,  Rzt  requires 
that  61  =  a2  =  aux_hash(&3, 04). 

□ 


Lemma  3.5  Let  II  and  Tz  =  {Tz1,Tz2,Tz3}  as  sPecified  Lemma.  3.4 ■  Then 

Va  e  E{H)G,  a  (=*  Tz2. 

Proof:  Analogous  to  the  proof  of  Lemma  3.4. 


□ 


Lemma  3.6  Let  11  and  Tz  =  {Tzl,Tz2,Tzz}  be  as  specified  in  Lemma .  3.4 •  Then 

Va  G  E(U)Ci  a  \=*  Tz$. 

Proof: 
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1.  Let  Sk  be  a  state  in  a  and  a4  a2  <23  a4:  t  x  t  x  t  x  t  be  a  message  such  that 

Si  |=  receive  (X,  a4  a2  a3  «4)  £  Hz  A  send(y,  a3)  £  Hz. 

Then  there  exists  a  state  s,.  i  <  k,  such  that 

S{  \=  receive (X,  Gi  a2  a3  a4)  £  Hz  A  last(Hz)  =  send(T,  a3). 

From  Lemma  3.4,  we  know  that  3  61  b2  b3  b4:  t  x  t  x  t  x  t  such  that 

Si  |=  receive(Y,  61  b2  b3  b4)  £  Hz. 

Thus,  we  only  need  to  prove  that 

Si  (=*  0(send(X,  b3)  £  Hz  V  (failRemote  £  HZA  fly  :  t  \  send(X,  y )  £  Hz)). 

2.  If 

Si  |=  last(Hz)  =  send(y,  03), 

then  sf  must  have  resulted  from  an  application  of  rules  Rz4  or  Rz6- 

3.  If  sf  resulted  from  applying  RZi,  then  RZl  is  the  only  rule  applicable  from  sf,  and  in  Z’s 
local  execution,  ‘send(y,  a3)’  can  be  followed  only  by  ‘send(y,  b3)'  or  ‘failRemote’.  This  means 
that  we  have 

Si  (=*  0(send  (X,  63)  G  Hz  V  (failRemote  G  HZA  /By  :t\  send  (X,y)  G  Hz)). 

In  this  case,  Z  sends  messages  first  to  Y,  then  to  X]  or  terminates  its  execution  after  sending 
the  message  to  Y. 

4.  If  sf  resulted  from  applying  Rz6 ,  then 

Si  (=  3y'3  :  t  I  send(X,  y'3)  £  Hz. 

This  means  that  3 j  <  i ,  and  a  message  b'3,  such  that 

Sj  \=  last(Hz)  =  send(X, 63). 

‘send(X,  63)’  could  have  resulted  only  from  applying  RZi,  which  prescribes  Z  to  send  b3  to 
X.  Thus,  b'3  =  b3. 

In  this  case,  Z  sends  messages  first  to  X,  then  to  Y . 

5.  From  3  and  4,  we  have: 

si  l=*  0((rh/i  :t,y2:t,y3:t,y4:t\  (receive(y,  y4  y2  y3  y4)  £  Hz  A  (send(X,  y3)  £  HZ)))V 

(failRemote  £  HZA  fly  :  t  |  send(X,  y)  £  Hz)). 

6.  The  other  conjunct  of  Tzz  can  be  proven  analogously. 


□ 
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3.5.2  Protection  Under  Compliance  Mode 

Proposition  3.7  Let  II  be  FR’s  protocol ,  a  be  an  execution  in  E(J[)C ,  and  Px  be  X ’s  protection 
property  as  specified  in  Section  3.3.2.  Then 


a  K  Px- 


Analysis: 

1.  Let  Si  be  a  state  such  that 

Si  \=  3x  :  t,  zx  :  t  \  receive(X,  x)  G  HY  A  receive(Z,  zx)  G  HY  A  unmask^*,  x)  = 
Then,  from  Lemma  3.22,  we  deduce  that  3j  >  i  \ 

Sj  \=  (3a:  3  :t,x4  :t  \  send(X,  x3)  G  Hz  A  receive  (y,  x4)  €  Hx)  V  failRemote  € 


2.  If  the  first  conjunct  is  true,  then  there  exist  messages  <13  :  t  and  a4  :  t  such  that 

Sj  \=  send(X,  a3)  €  Hz  A  receive^,  a4)  G  Hx. 

According  to  Lemma  3.23,  unmask(a3,  a4)  =  Ky. 

Two  scenarios  can  be  derived  from  here. 

(a)  If  the  communication  channel  between  X  and  Z  does  not  fail,  then  X  will  receive  the 
message  sent  by  Z ,  i.e.,  3k,  k  >  j  \ 

Sk  1=  receive (Z,  a3)  G  Hx  A  receive(y,  a 4)  G  Hx. 

And  from  2)  we  know  that  unmask(a3,  a4)  =  Ky. 

(b)  If  the  communication  channel  between  X  and  Z  fails  before  X  receives  a3  from  Z,  then 
VM>i’ 

s;  |=  receive(y,  a4)  G  HXA  flx2  ■  t  |  receive  (Z,  X2)  G  H. 

3.  If  the  first  conjunct  is  false,  then 

Sj  1=  failRemote  G  HZA  fly  :  t  \  send(X,  y)  G  Hz. 

This  is  the  scenario  where  Z  is  prevented  from  sending  messages  to  X  because  of  a  failure  in 
the  communication  channel.  Like  2b),  we  can  conclude  that 

Ml,  l  >  j,  si  \=  receive(y,  a4)  G  HXA  flx%  '■  t  \  receive (Z,  *2)  €  Hx. 


4.  From  2)  and  3),  we  conclude  that  this  proposition  holds  if  the  communication  channel  between 
X  and  Z  does  not  fail.  Otherwise,  it  does  not. 


□ 
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The  next  two  lemmas  are  used  in  the  analysis  of  Proposition  3.7.  Lemma  3.22  says  that  if  Y 
has  received  a  message  from  Z,  then  Z  will  have  sent  a,  message  to  X,  and  X  will  have  received  a. 
message  from  Y ;  or  Z  will  have  failed  to  send  a  message  to  X  because  of  a  communication  channel 
failure. 

Lemma  3.22  Let  IT  be  FR’s  protocol  and  c  be  an  execution  in  E(Yl)c . 

o  |=*  □  (3xj  :  t  |  receive^,  Xi)  £  HY  — > 

O  ((3x2  '■  t,x3  :t  \  send(X,  x2)  €  Hz  A  receive(Y,  x3)  £  Hx)  V  failRemote  £  H2)). 

Proof: 

1.  Let  Si  be  a  state  in  a  and  a4  :  t  be  a  message  such  that 

Si  |=  receive(Y,  di)  £  HY. 

By  communication  assumption  (Definition  2.10,  condition  6), 

Si  \=  send(Y,  ai)  €  H2. 

2.  send^(Y,  ax)  could  have  been  prescribed  by  rules  Rz4  or  Rz6- 

3.  If  send^(Y,  di)  resulted  from  an  application  of  Rz4,  then  3 j  <  i  \ 

Sj  |=  send(Y,  a4)  ^  HzA  flx4  :  t  |  send(X,  x4)  £  H2, 

and 

Sj+i  |=  last(Hz)  =  send(Y,  di)A  flx4  :  t  |  send(X,  x4)  £  Hz. 

4.  Rz7  is  the  only  rule  applicable  from  s^+1,  which  implies  that 

Sj+i  |=*  <>  (3x4  :  t  |  send(X,  X4)  £  Hz  V  failRemote  £  Hz), 

and  consequently 


Si  f=*  O  (3x4  :  t  |  send(Y,  X4)  £  H2  V  failRemote  £  Hz). 

5.  If  send^(Y,  di)  resulted  from  an  application  of  Rz6,  then  Z  sent  a  message  to  X  before  it 
sent  messages  to  Y.  That  is 


Si  f=*  3x4  :  t  |  send(X,  x4)  £  Hz, 

and  consequently 

Si  |=*  O  (3x4  :  t  |  send(X,  X4)  £  Hz). 
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6.  Next,  let  us  prove  that 


Si  J=*  O  (3a;3  :  t  |  receive(Y,  x3)  £  Hx). 
By  straightforward  backchaining, 

Si  (=  send(F,  ai)  £  Hz 


implies  that  3k  <  i  \ 

Sk  1=  3x  :  t  X  t  X  t  X  t  |  receive(X,  a:)  £  Hz, 
which,  by  communication  assumption,  implies  that 

Sk  \=  3x  :  t  X  t  X  t  X  t  \  send(Z,  x)  £  Hx. 


7.  Since  ‘send-to-Z’  events  are  only  prescribed  by  Rxz,  and  i?x5’s  enabling  condition  requires 
a  ‘receive-from-Y’  event,  we  can  conclude  that 

Sk  |=  3a:  :  t  |  receive  (Y,  x)  £  Hx, 

and  consequently 

Si  |=*  O  (3a;3  :  t  \  receive (Y,  3:3)  £  Hx). 

8.  Given  4),  5)  and  7),  the  lemma  is  proved. 


□ 


Lemma  3.23  says  that  the  message  sent  to  X  by  Z  and  the  message  X  receives  from  Y  form  a 
correct  splitting  of  Y’s  secret. 

Lemma  3.23  Let  II  be  FR’s  protocol  and  o  be  an  execution  in  J5'(II)C.  Then  V  a?2  :  t,  X3  :  t, 
o  |=*  □  (send(X,a:2)  £  Hz  A  receive (Y,  a;3)  £  Hx  — ^  unmask(a:2,  3:3)  =  Ky). 


Proof:  Let  sn  be  a  state  such  that  there  exists  messages  02  and  03  such  that 

sn  |=  send(X,  02)  €  Hz  A  receive(Y,  03)  £  Hx. 

Then,  we  can  prove  the  lemma  as  follows: 

1.  Given 

sn  |=  send(X,  a2)  E  Hz, 

we  can  conclude,  by  straightforward  backchaining,  that 

sn  |=  3aq  X2  X3  X4  :  t  X  t  X  t  X  t  \  receive(Y,  Xi  a:2  3:3  x4)  £  Hz, 
and  that  the  third  component  of  this  concatenated  message  is  02,  i.e., 

sn  (=  33:1  :  t,X2  :  t,x4  :  t  \  receive(Y,  [sq,  X2, 02,  x4])  £  Hz. 
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2.  By  communication  assumption, 

sn  f=  3x\  :  t,x2  :  t,x4  :  t  \  receive(Y,  [a?i,  x2, a2,  *4])  €  Hz 

implies  that 

sn  |=  3a;i  :t,x2:t,x4:t\  send (A,  [x4,  x2,  a2,  £4])  G  HY. 

And  since  Rys  is  the  only  rule  that  prescribes  a  “send-to-Z”  event,  we  can  conclude  that 

a2  =  mask(K!/,  ai), 

for  a  message  a\  :  t ,  and 

sn  [=  send(A', aj)  G  HY. 

3.  Also,  by  communication  assumption, 

sn  1=  receive  (Y,  a3)  G  Hx 

implies  that 

sn  |=  send(X,  o3)  6  HY. 

Given  that  there  can  be  only  one  send-to-Z  event  in  HY,  we  conclude  that  ci  =  a3. 

4.  We  are  now  ready  to  show  that  unmask(c2,  a3 )  =  Ky.  From  2),  we  know  that  a2  =  mask(Kv,  a3). 
Thus,  unmask(a2j  03)  =  unmask(mask(Ky,  03),  a3)  —  ny. 

□ 


3.5.3  Protection  Under  Abortion  Mode 

Proposition  3.12  Let  II  be  FR’s  protocol,  a  be  an  execution  in  T  be  the  trust  assumptions 

IT  makes,  and  Px  be  X ’s  protection  property  as  specified  in  Section  3.3.2.  Then 

a  |=*  T  implies  a  f=*  Px. 

Analysis:  The  structure  of  this  analysis  is  identical  to  the  structure  of  the  analysis  of  Proposi¬ 
tion  3.7;  the  lemmas  it  uses  are  in  one-to-one  correspondence  to  those  used  by  Proposition  3.7.  We 
repeat  the  analysis  here  for  self-containment. 

1.  Let  Si  be  a  state  such  that 

Si\=3x  :t,zx:t\  receive(X,  i)eHYA  receive(Z,  zx)  e  HY  A  unmask^*,  x)  =  kx. 

Then  from  Lemma  3.24,  we  deduce  that  3 j  >  i  \ 

Sj  \=  (32:3  :  t,  x4  :  t  |  send(X,  *3)  G  Hz  A  receive(Y,  x4)  €  HX)V 

failRemote  G  Hz. 

2.  If  the  first  conjunct  is  true,  then  there  exist  messages  a3  :  t  and  a4  :  t  such  that 

sj  |=  send  (A,  a3)  G  Hz  A  receive(Y,  04)  G  Hx. 

According  to  Lemma,  3.25,  unmask(a3, 04)  =  Ky. 

Two  scenarios  can  be  derived  from  here. 
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(a)  If  the  communication  channel  between  X  and  Z  does  not  fail,  then  X  will  receive  the 
message  sent  by  Z,  i.e.,  3k,  k  >  j  \ 

Sk  |=  receive  (Z,  a3)  G  Hx  A  receive(Y,  a4 )  6  Hx. 

And  from  2)  we  know  that  unmask(a3,  a4)  =  /%. 

(b)  If  the  communication  channel  between  X  and  Z  fails  before  X  receives  a3  from  Z ,  then 

vu>j,  ,  x 

si  |=  receive  (Y,  a4)  G  HXA  flx 2  :  t  |  receive (Z,  *2)  G  H  . 

3.  If  the  first  conjunct  is  false,  then 

sj  f=  failRemote  G  HZA  fly  't  |  send(X,  y)  G  Hz. 

This  is  the  scenario  where  Z  is  prevented  from  sending  messages  to  X  because  of  a  failure  in 
the  communication  channel.  Like  2b),  we  can  conclude  that 

V/,/  >  j,  si  \=  receive(Y,  04)  G  HXA  flx3  :  t  |  receive(Z,  *2)  £  HX- 

4.  From  2)  and  3),  we  conclude  that  this  proposition  holds  if  the  communication  channel  between 
X  and  Z  does  not  fail.  Otherwise,  it  does  not. 

□ 

Note  that  we  did  not  refer  to  trust  assumptions  in  the  analysis  of  Prop.  3.12.  In  fact,  we  only 
need  them  in  the  proof  of  Lemma  3.24.  This  fact  is  reflected  in  the  statements  of  the  lemmas 
used  by  Proposition  3.12  (Lemmas  3.24  and  3.25):  Lemma  3.24  is  the  only  one  whose  statement 
mentions  trust  assumptions. 

Lemma  3.24  Let  II  be  FR’s  protocol  and  o  be  an  execution  in  E(  11)^.  Then 

a  \=*  T  implies  a  |=*  □  (3*i  :  t  \  receive (Z,  x x)  G  HY  -4 

O  ((3*2  :  t,  *3  : 1 1  send  (A,  *2)  €  Hz  A  receive(Y,  *3)  G  Hx)  V 
failRemote  G  Hz). 

Proof: 

1.  This  proof  uses  some  of  the  reasoning  steps  used  in  the  proof  of  Lemma  3.22.  More  specifically, 

0  [=*  □  (3*i  :  t  |  receive(Z,  *1)  G  HY  — >  3*3  :  t  \  receive(Y,  *3)  G  Hx) 

can  be  proven  using  steps  1,  6,  and  7  in  that  proof.  Steps  1,  2,  and  5  prove  that  a  send^  (X,  *2) 
event  could  have  preceded  send^(Y,  ai)  in  cr. 

2.  But  if  send^(Y,  ai)  was  not  preceded  by  asend^(A,  *2)  event,  and  a  is  an  arbitrary  member 
of  £?(II)^,  then  an  occurrence  of  send^(Y,  a  1)  may  be  followed  by  an  occurrence  of  ‘failLocal’. 
That  is,  steps  3  and  4  (in  the  proof  of  Lemma  3.22)  does  not  always  hold  of  an  execution 
a  G  E( II)f 
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3.  However,  let  Sj  be  the  state  in  a  such  that 


Sj  |=  send(y,  ax)  Hz  and  sJ+x  \=  last(Hz)  =  send(y,  ax). 

(a)  By  straightforward  backchaining, 

Sj+i  (=  send (y,ax)  £  Hz 

implies  that  3k  <  j  and  b4  b2  b3  64 :  t  x  t  x  i  x  t  such  that 

st-  |=  receive(X,  6X  62  63  £>4)  £HZ  A  ax  =  63. 

Thus, 

Sj+i  (=  receive (X,  6X  b2  b3  b4)  £  Hz  A  last(Hz)  =  send(y,  63). 

(b)  Given  that  a  f=*  Tz3 , 

a  (=*  □(3a:1  :  t,  x2  :  t,  x3  :  t,  x4  :  t  |  (receive(X,  *1  a;2  x3  z4)  £  H  A  last(H)  =  send(y,  ,r3)  -> 
0((3yj  ■t,y2:t,y3:t,y4:t\ 

(receive(y,  yx  y2  y3  y4)  £  H  A  (send(X,  y3)  £  H)))V 
(failRemote  £  HA  fly  :  t  |  send(X,  y)  £  H)))). 

This  implies  that  3i  >  j  +  1  such  that 

Si  |=  3y3  :  t  |  send  (X,  y3)  £  Hz  V  failRemote  £  Hz. 


□ 

The  proof  above  shows  that  the  liveness  condition  specified  in  Lemma  3.24  does  not  hold  in 
all  executions  <7  £  £(II)^.  It  is  violated  in  executions  where  local  factors  cause  Z  to  terminate  its 
execution  after  it  sends  its  share  of  X’s  secret  to  Y,  but  before  it  sends  its  share  of  y’s  secret  to 
X.  If  we  consider  only  trustworthy  executions,  however,  the  liveness  condition  is  never  violated 
because  of  T z:_, . 

Lemma  3.25  corresponds  to  Lemmas  3.23.  Unlike  Lemma  3.24,  it  holds  in  all  executions  o  £ 

mrt- 

Lemma  3.25  Let  II  be  FR’s  protocol  and  o  be  an  execution  in  £'(11)^.  Then  V  X\  :  t,  x2  :  t,  x3  :  t, 
a  |=*  □  (send(X,  x2)  £  Hz  A  receive (y,  £3)  £  Hx  — >•  unmask (x2,  x3)  =  Ky). 

Proof:  Identical  to  that  of  Lemma  3.23. 

□ 
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3.5.4  Protection  Under  Deception  Mode 

Proposition  3.17  Let  II  be  FR’s protocol,  o  be  an  execution  in  E{  11)$,  T  be  the  trust  assumptions 
II  makes,  and  Px  be  X ’s  protection  property  as  specified  in  Section  3.3.2.  Then 

a  \=*  T  implies  a  |=*  Px  ■ 

Analysis:  The  structure  of  this  analysis  is  identical  to  the  structure  of  the  analysis  of  Proposi¬ 
tion  3.7;  the  lemmas  it  uses  are  in  one-to-one  correspondence  to  those  used  by  Proposition  3.7.  We 
repeat  the  analysis  here  for  self-containment. 

1.  Let  S{  be  a  state  such  that 

Si  \=  3x  :  t,  zx  :  t  \  receive(A,  x)  G  HY  A  receive(Z,  zx)  G  HY  A  unmask^*,  x )  =  kx. 

Then,  from  Lemma  3.26,  we  deduce  that  3,;  >  i  | 

Sj  |=  (3^3  :  t,  x4  :  t  |  send(A,  *3)  G  Hz  A  receive(Y,  x4)  €  Hx)  V  failRemote  G  Hz. 

2.  If  the  first  conjunct  is  true,  then  there  exist  messages  o3  :  t  and  a4  :  t  such  that 

Sj  |=  send  (A,  o3)  G  Hz  A  receive  (Y,  a4)  G  Hx. 

According  to  Lemma  3.27,  unmask(a3,  a4)  =  Ky. 

Two  scenarios  can  be  derived  from  here. 

(a)  If  the  communication  channel  between  X  and  Z  does  not  fail,  then  X  will  receive  the 
message  sent  by  Z,  i.e.,  3k,  k  >  j  \ 

Sk  |=  receive  (Z,  a3)  G  Hx  A  receive(Y,  a4)  G  Hx. 

And  from  2)  we  know  that  unmask(o3,  a4)  =  Ky. 

(b)  If  the  communication  channel  between  X  and  Z  fails  before  X  receives  a3  from  Z ,  then 

VM>i,  Y 

si  |=  receive(Y,  afi)  G  HXA  /3x2  '■  t  \  receive (Z,  xfi)  G  HA. 

3.  If  the  first  conjunct  is  false,  then 

Sj  \=  failRemote  G  HZA  jBy  :  t  |  send(A,  y)  G  Hz. 

This  is  the  scenario  where  Z  is  prevented  from  sending  messages  to  X  because  of  a  failure  in 
the  communication  channel.  Like  2b),  we  can  conclude  that 

V/,  l  >  j, si  |=  receive(Y,  a4)  G  HXA  flx2  :  t  \  recei ve(Z,  *2)  €  Hx. 

4.  From  2)  and  3),  we  conclude  that  this  proposition  holds  if  the  communication  channel  between 
X  and  Z  does  not  fail.  Otherwise,  it  does  not. 


□ 
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Lemma  3.26  corresponds  to  Lemmas  3.22  and  3.24.  It  holds  in  all  executions  a  G  £(11)^. 

Lemma  3.26  Let  II  be  FR’s  protocol  and  a  be  an  execution  in  E(Yl)^. 

(j  j=*  □  ( 3x\  :  t  |  receive (Z,  *1)  G  HY 

O  ((3a;2  :  t,  x3  :  t  \  send  (A,  x2)  €  Hz  A  receive(Y,  z3)  G  Hx)  V  failRemote  G  Hz)). 
Proof:  Identical  to  that  of  Lemma  3.22. 


□ 

Lemma  3.27  corresponds  to  Lemmas  3.23  and  3.25.  It  is,  however,  more  complex.  The  safety 
condition  that  appears  in  Lemmas  3.23  and  3.25  is  now  specified  to  hold  in  trustworthy  executions 
where  Y  has  received  the  two  shares  of  A’s  secret.  This  should  have  been  expected,  given  that 
under  the  deception  mode,  there  is  no  guarantee  whatsoever  of  what  the  principals  may  send  to 
each  other.  Unless  Z  forwards  what  it  should  to  Y  and  behaves  according  to  the  trust  assumptions, 
no  guarantee  can  be  given  about  the  message  A  receives  from  Y  and  the  one  Z  sends  to  X. 

Lemma  3.27  Let  IT  be  FR’s  protocol  and  a  be  an  execution  in  E( Il)§.  Then  Vy  :  t,zy  :  t, 

a  |=*  T  implies 

a  |=*  a  (3x  :  t,  zx  :  t  \  (receive(A,  *)  G  HY  A  receive(Z,  zx)  G  HY  A  unmask^*,  x)  =  kx)  -4 
(receive(Y,  y)  G  Hx  A  send  (A,  zy)  G  Hz)  -4  unmask {zy,  y)  =  kv). 

Proof:  Let  Sj  be  a  state  such  that 

Sj  |=  3x  :  t,  zx  :  t  |  receive(Y,  x)  G  Hy  A  receive(Z,  zx)  G  HY  A  unmask^*,  x)  =  kx. 

And  assume  that  3 zy  :t,y:t  such  that 

Sj  \=  send(X,  zy)  G  Hz  A  receive(Y,  y)  G  Hx. 

If  cx,  dx,  cy,  and  dy  are  messages  such  that 

Sj  (=  receive  (A,  cx )  G  HY  A  receive(Z,  dx)  G  HYA 
send  (A,  dy)  G  Hz  A  receive  (Y,  cy)  G  Hx, 

then  we  want  to  prove  that  unmask(<4,  cy)  =  ny. 

1.  According  to  Lemma  3.28, 

Sj  (=  receive(A,  cx)  G  HY  A  receive(Z,  dx)  G  HY  A  unmask(<4,  cx )  =  kx 

implies  that 

Sj  \=3xi . .  ,x4  :t  x  t  x  t  xt  \  (receive (A,  x\  . .  .x4)  G  Hz  A  send(Y,  *3)  G  Hz), 
which  implies,  according  to  rules  Rz4  and  Rz6,  that 

Sj\=3y1...y4:txtxtxt\  (receive(Y,  yi . .  .y4)  €  Hz  A  yx  =  x2  =  aux_hash(y3,  x4). 

In  what  follows,  let  a\. .  ,a4  and  61 . .  .64  be  such  that 

Sj  |=  receive  (A,  ai . .  ,a4)  G  Hz  A  receive(Y,  b\  . .  .64)  G  Hz. 

Thus,  Sj  | —  b4  =  a2  =  aux_hash(£>3,  a4). 
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2.  From 


Sj  1=  receive (X,  ai . .  .04)  G  Hz  A  send(y,  03)  G 

Sj  (=  send(X,  dy )  €  Hz  A  receive(Y,  b\ ...  64)  € 

Tz3,  and  the  fact  that  there  can  be  only  one  ‘receive-from-Y’  event 
event  at  Z,  we  can  conclude  that  dy  =  63. 

3.  From 


sj  |=  receive(X,  ai . .  ^4)  G  Hz 
we  can  conclude,  by  communication  assumption,  that 


Hz, 

HZ, 

and  only  one  ‘send-to-X’ 


Sj  |=  send(Z,  cq . .  .04)  €  Hx. 


And,  according  to  Lemma  3.29, 

Sj  |=  (a2  =  hash(Ky))  A  (3k  :  t  |  receive(Y,  k)  €  Hx  A  hash(fc)  =  a4). 
Since  there  can  be  only  one  ‘receive-from-Y’  event  at  X ,  and 

Sj  (=  receive  (Y,  Cj,)  €  Hx, 


we  conclude  that  hash(cy)  =  a4. 

4.  We  are  now  ready  to  prove  that  unmask(dy,  cy)  =  ny. 


hash(Ky)  =  a2  — 


aux_hash(&3, 04) 
aux_hash(i>3,  hash(cy)) 
hash(unmask(&3,  cy)) 
hash(unmask(dy,  cy)). 


□ 

Lemma  3.28  is  an  auxiliary  lemma  used  in  the  proof  of  Lemma  3.27.  It  establishes  a  straight¬ 
forward  result  about  sequencing  of  events  and  holds  for  all  executions  a  €  E(T1)%. 

Lemma  3.28  Let  II  be  FR’s  protocol  and  a  be  an  execution  in  £(11)^.  Then 

a  |=*  shareable^,  {A})  — >• 

□  (3x  :t,zx:t\ 

(receive(X,  x)  €  HY  A  receive(Z,  zx )  €  HY  A  unmask^*,  x)  =  kx)  — t 
3x\  ...x4:txtxtxt\ 

receive  (A,  x4 . . .  x4)  G  Hz  A  send(Y,  *3)  G  Hz). 

Proof: 

1.  Let  sn  be  a  state  and  mi  and  m2  be  messages  such  that 

sn  \=  receive (X,  mi)  G  HY  A  receive(Z,  m2)  G  HY  A  unmask(m2,  mi)  =  kx. 
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2.  By  communication  assumption 


sn  |=  receive(Z,  m2)  G  HY 

implies  that 

sn  |=  send(y,  m2)  G  Hz. 

3.  From  straightforward  backchaining,  we  know  that 

sn  |=  3a:  1  . .  .x4  :  t  X  t  X  t  X  t  \  receive(W,  X\ . .  .X4)  G  Hz. 
In  what  follows,  let  x\ . .  ,x4  be  a\  . .  .0,4.  We  want  to  prove  that 

unmask (m2,  mi).  =  nx  — y  m2  =  <23, 

or  equivalently, 

m2  /  — y  unmask(m2,  mi)  / 

4.  We  first  find  out  the  structure  of  a3. 

(a)  By  communication  assumption, 

|=  receive^,  ai . .  .a4)  G  Hz 

implies 

5n  [=  send(Z,  ai . .  .a4)  G  Hx, 

which,  according  to  rule  implies  that  3 i  <  n,g  :t  such  that 

S{  send(Z,  ax  . .  .a4)  ^  Hx  A  send  (Y,  51)  £  Hx, 


and 

s;_l_i  |=  last(Hx)  =  send(Z,  a\  . .  .a4)  Aas  =  mask^,  <7). 

(b)  From  1)  we  know  that  sn  |=  receive (X,  mi)  G  HY,  which,  by  communication  assumption, 
implies  that  that  sn  |=  send(y,  mi)  G  Hx. 

(c)  Since  only  one  ‘send-to-Y’  event  could  have  happened  at  X ,  we  conclude  that  g  =  mx. 

(d)  Since  as  =  mask^,  </)  and  g  =  mi,  we  can  conclude  that 

unmask(a3,  mi)  = 

5.  Next,  we  prove  that  m2  ±  a3  — ►  unmask(m2,  mx)  /  kx.  If  m2  /  a3,  then  m2  /  masA^/c*,  </). 
Then  m2  could  be: 

(a)  a  basic  message; 

(b)  m2  =  mask(&i,  &2),  where  61  7^  or  b2  ^  g\ 

(c)  m2  =  unmask(6i,  62); 

(d)  m2  =  hash(6i);  or 

(e)  m2  =  aux_hash(&iT  62). 
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All  the  values  above  are  such  that  unmask  (m2,  g)  7^  kx- 

□ 

Lemma  3.29  is  also  an  auxiliary  lemma  used  in  the  proof  of  Lemma  3.27.  It  concerns  the  values 
of  the  second  and  the  fourth  components  of  the  message  X  sends  to  Z\  the  second  component  is 
the  hash  of  Y’s  secret,  and  the  fourth  component  is  the  hash  of  the  message  it  receives  from  Y. 
This  lemma  is  true  because  we  are  considering  only  executions  where  X  is  compliant.  It  may  not 
be  true  otherwise. 

Lemma  3.29  Let  a  €  _E(II)^.  Then 

a  (=*  □  ( 3a;  1  . . .  x4  :  t  X  t  X  t  X  t  \  (send  ( Z,  x4 . . .  £4)  GHx-t 

(#2  =  hash(Ky)  A  3k  :  t  |  receive(Y,  k)  6  Hx  A  hash(Ai)  =  £4))). 


Proof: 

1.  Let  Sj  be  state  and  a4 . .  .a4  :  t  x  . . .  X  t  be  a  message  such  that 

Sj  (=  send(Z,  aj . .  .a4)  £  Hx. 

Then,  <  j  such  that  s;  is  the  state  at  which  the  event  occurred,  i.e., 

Sj  |=  send(Z,  a4 . . .  a4 )  ^  Hx  and  Sj+i  |=  send(Y,  a4 . .  .a4 )  €  Hx. 

2.  Since  Rx&  is  the  only  protocol  rule  that  prescribes  a  ‘send-to-Z’  event,  and  X  behaves  com¬ 
pliantly  in  <7,  we  can  conclude  that 

(a)  a2  =  py,  and 

(b)  a4  =  hash(c),  where  c  is  such  that  Sj  |=  receive(Y,  c)  6  Hx, 

which  is  exactly  what  we  want  to  conclude,  given  that  py  =  hash(«3/)  according  to  the  initial 
conditions. 

□ 


3.6  Summary 

In  this  section,  we  summarize  the  findings  of  our  analysis  and  discuss  our  contributions  towards 
formalizing  semi-trustworthiness. 

Table  3.7  summarizes  our  findings.  All-protection  is  guaranteed  in  entries  with  a  Some 
entries  come  with  briefings  of  relevant  facts.  Note  that  the  protocol  is  not  all-protective  if  com¬ 
munication  links  can  fail.  To  be  fair,  Franklin  and  Reiter  assume  reliable  links,  even  though  this 
assumption  does  not  appear  explicit  in  their  paper. 

As  we  mentioned,  Franklin  and  Reiter’s  protocol  is  an  ideal  candidate  for  our  case  study  because 
it  uses  semi-trusted  intermediaries.  Franklin  and  Reiter  define  semi-trusted  intermediaries  as  those 
that  can  misbehave  on  their  own,  but  do  not  conspire  with  either  of  the  main  parties.  Implicit  in 
this  definition  is  the  concept  of  intermediaries  that  can  misbehave  in  certain  ways  (misbehavings  of 
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compliance 

abortion 

deception 

Channel  Failures 

(i) 

(i) 

(i) 

No  Channel  Failures 

V 

V(2) 

V(3) 

(1)  All-protection  is  violated  if  Z  cannot  execute  the  second  forward,  or  if  one  of 
the  forwarded  messages  does  not  get  to  its  destination. 

(2)  If  X  terminates  her  execution  before  sending  the  second  share  of  her  secret  Kx 
to  Z ,  she  will  receive  nothing  from  Z  and  will  not  be  able  to  obtain  Ky.  If  she 
terminates  her  execution  after  sending  the  second  share  of  I<x  to  Z ,  no  harm 
(except  to  herself)  can  be  made.  The  same  reasoning  applies  to  Y.  Z  is  trusted 
not  to  terminate  its  execution  between  forwarding  messages  to  X  and  Y . 

(3)  Deceptions  by  either  X  or  Y  are  detectable  by  Z.  And  Z  is  trusted  not  to 
deceive  unfairly. 

Figure  3.7:  Summary  table 

their  own  or  “plain”  misbehavior),  but  not  in  others  (misbehavings  that  are  conspiracy).  Franklin 
and  Reiter  did  not  precisely  characterize  either  plain  misbehaviors  or  conspiracy  misbehaviors, 
however.  In  their  failure  model,  only  one  principal  can  fail  or  misbehave  in  each  execution,  and 
there  is  no  restriction  on  how  the  intermediary  can  fail  or  misbehave. 

Even  though  they  do  not  define  conspiracy  behaviors,  they  classify  the  execution  in  Fig.  3.5  as 
exhibiting  conspiracy  behavior.  Instead  of  ignoring  them  in  their  analysis  of  the  protocol  (since 
these  behaviors  are  not  exhibited  by  semi-trusted  intermediaries),  they  took  them  into  account, 
and  questioned  whether  the  protocol  should  offer  protection  against  conspiracies. 

These  intuitive  notions  of  conspiracy  and  semi-trustworthiness  are  precisely  captured  in  our 
framework.  Plain  misbehaviors  are  deviations  that  do  not  violate  trust  assumptions;  conspiracy 
misbehaviors  are  those  that  do;  and  semi-trusted  intermediaries  are  those  that  exhibit  only  plain 
misbehaviors. 
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Chapter  4 

The  NetBill  Protocol 

In  this  chapter,  we  present  our  second  case  study,  the  NetBill  Protocol  [28]  proposed  by  Cox, 
Tygar  and  Sirbu.  We  specify  the  protocol  in  our  protocol  specification  formalism,  and  analyze  it 
with  respect  to  protection  of  individuals’  interests  using  our  framework.  Since  we  are  interested  in 
protection  of  all  parties  equally,  we  analyze  it  with  respect  to  all-protection. 

NetBill  differs  from  Franklin  and  Reiter’s  protocol  in  the  type  of  intermediaries  they  use.  In 
Franklin  and  Reiter’s  protocol,  the  intermediary  is  a  “stranger”  that  has  no  further  responsibility 
once  the  on-line  exchange  is  finished.  In  NetBill,  the  intermediary  is  a  server  that  has  a  role  to 
play  even  after  transactions  have  occurred.  NetBill  supports  off-line  dispute  resolutions,  and  the 
NetBill  server  is  the  one  to  provide  critical  messages  to  enable  such  resolutions. 

The  NetBill  protocol  is  the  second  in  complexity  (among  the  three  we  analyze),  but  its  protec¬ 
tion  properties  are  the  most  complex.  They  are  complex  because  the  notion  of  protection  required 
here  is  open;  and  one  needs  to  take  into  account  not  only  goods  and  payments  exchanged  on-line, 
but  also  other  messages  exchanged  between  the  participants.  It  is  critical  to  consider  these  mes¬ 
sages  because  they  prove  what  happened  on-line;  with  these  messages,  participants  can  claim  what 
they  are  entitled  to,  but  did  not  get  on-line. 

Our  analysis  does  not  reveal  any  surprises.  NetBill  is  both  customer-protective  and  merchant- 
protective  under  all  three  deviation  modes,  even  when  communication  links  can  fail.  NetBill  is  not 
affected  by  link  failures  because  the  NetBill  server  is  assumed  to  be  permanently  reachable. 

Our  analysis  does  make  explicit,  however,  interesting  points  about  how  the  protocol  guarantees 
all- protection,  and  what  the  NetBill  server  is  trusted  to  do.  Under  compliance  and  abortion  modes, 
all-protection  is  guaranteed  by  the  server’s  transaction  capabilities  alone;  certified  delivery  is  needed 
only  under  deception  mode.  More  interestingly,  certified  delivery  achieves  its  goals  only  if  the 
NetBill  server  satisfies  a  small  set  of  trust  assumptions.  Basically,  the  server  is  entrusted  to  handle 
accounts  and  keys  honestly;  to  provide  unique  and  non-repudiable  proofs  of  what  happens  on-line 
through  transaction  slips;  and  to  allow  merchants  to  learn  what  really  happens  with  a  transaction 
-  so  that  keys  are  not  given  to  customers  without  their  knowledge.  Even  though  it  may  seem 
counter-intuitive  at  first,  NetBill’s  all-protection  does  not  depend  on  the  server’s  releasing  the  keys 
that  merchants  send  it,  or  its  retaining  transaction  requests. 

The  rest  of  this  chapter  is  structured  as  follows.  In  Section  4.1,  we  introduce  the  protocol 
and  assumptions  made  by  its  designers.  In  Section  4.2,  we  present  an  abstract  formulation  of 
the  mathematical  building  blocks  used  in  it.  In  Section  4.3,  we  formalize  both  the  protocol  and 
the  protection  properties.  In  Section  4.4,  we  show  the  main  results  and  their  high-level  analyses. 
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Formal  analyses  of  these  results  are  found  in  Section  4.5.  Finally,  in  Section  4.6,  we  summarize  the 
findings  from  Sections  4.4  and  4.5,  and  discuss  insights  gained  through  our  exercise. 


4.1  Introduction 

In  this  section,  we  introduce  the  NetBill  protocol.  The  version  presented  here  is  in  reality  an 
abstract  version  of  the  one  given  in  [84].  We  first  give  some  preliminary  remarks  (Section  4.1.1), 
then  present  the  protocol  (Section  4.1.2),  and  finally  discuss  our  abstractions  (Section  4.1.3). 

4.1.1  Preliminaries 

NetBill  was  designed  to  enable  sales  of  information  goods  -  goods  deliverable  over  the  network.  It 
aims  to  guarantee  three  levels  of  atomicity  [84]:  money  atomicity,  goods  atomicity,  and  certified 
delivery.  According  to  Tygar,  a  protocol  is  money-atomic  if  it  transfers  funds  from  one  party  to 
another  without  the  possibility  of  creation  or  destruction  of  money;  a  protocol  is  goods-atomic  if  it 
is  money-atomic  and  guarantees  exchange  of  goods  for  money;  finally,  a  protocol  satisfies  certified 
delivery  if  it  is  goods-atomic  and  provides  means  for  both  merchants  and  customers  to  prove  what 
goods  were  delivered. 

Goods  atomicity  is  different  from  Franklin  and  Reiter’s  fair  exchange  property.  Goods  atomicity 
only  guarantees  that  money  is  exchanged  for  something  -  not  necessarily  what  the  customer  pays 
for.  To  guarantee  that  customers  receive  what  they  pay  for,  NetBill  relies  on  certified  delivery, 
which  allows  customers  and  merchants  to  prove  what  happened  on-line  and  settle  disputes  off-line. 

Transactions  in  NetBill  involve  three  principals:  a  customer  C,  a  merchant  M,  and  an  inter¬ 
mediary  N  -  the  NetBill  server.  C  and  M  may  be  untrustworthy,  but  N  is  assumed  to  be  trusted. 
For  the  remainder  of  this  chapter,  we  refer  to  C,  M,  and  N  respectively  as  she,  he  and  it.  All 
principals  have  public  key  pairs.  Public  keys  are  certified  before  keys  are  used.  Private  keys  are 
used  to  sign  selected  messages  for  accountability.  C  and  M  have  their  keys  certified  by  N,  whereas 
N  has  its  key  certified  by  an  entity  external  to  the  system. 

Both  C  and  M  must  have  accounts  with  N.  Accounts  are  uniquely  associated  with  account 
holders’  ids  and  public  keys.  Besides  holding  accounts  for  C  and  M,  N  mediates  transactions  and 
transfers  funds  between  different  accounts  when  parties  need  to  pay  each  other. 

Sale  transactions  in  NetBill  consist  of  four  logical  phases:  ordering,  goods  delivery,  payment, 
and  dispute  resolution.  And  each  sale  transaction  (informal  sense)  corresponds  to  a  distributed 
transaction  (technical  sense)  involving  C,  M,  and  N.  Ordering  in  NetBill  is  simple:  to  order,  C 
sends  M  a  message  specifying  the  goods.  Goods  delivery  happens  in  two  steps.  First,  M  encrypts 
the  goods  and  delivers  it  directly  to  C ;  then,  after  the  payment,  the  decryption  key  is  released  - 
either  by  M  itself  or  through  N.  Payments  happen  at  N.  Upon  receiving  a  transaction  request 
from  M,  N  may  commit  or  abort  the  transaction.  If  the  transaction  commits,  N  releases  a  signed 
slip  attesting  to  the  result  of  the  transaction.  The  result  can  be  successful  or  unsuccessful.  If  the 
result  is  successful,  N  transfers  funds  from  C’s  account  to  M’s  account  and  releases  the  decryption 
key  in  the  slip.  If  the  result  is  unsuccessful,  no  funds  are  transferred,  and  the  decryption  key  is  not 
released.  Dispute  resolution,  if  needed,  happens  off-line,  with  the  help  of  an  outside  arbitrator. 
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1.  C  — >■  M  :  order 

2.  M-*C:  enc(g,k)  cc(enc(g,k))  t 

3.  C  — ¥  M  :  epo  seal(epo ,  A:'1), 

where  epo  =  c  cc(enc(g,  k ))  t , 

4.  M  — »■  TV  :  tr  seal(tr,  A;"1), 

where  tr  =  m  signed. epo  k  and 

signed. epo  —  epo  seal  (  epo,  kf1) 

5.  TV  -4  M  :  slip  seal  (slip,  k~l) 

where  slip  =  result  c  m  transferred  k  t, 

6.  M  — C  :  slip  seal(slip,k~l) 

where  slip  —  result  c  m  transferred  k  t . 

The  various  symbols  denote: 

order  :  a  predefined  message  for  requesting  the  goods; 
k-1,^1^-1  :  respectively  C,  M,  and  TV’s  private  keys; 

c,  m  :  respectively  C’s  and  M’s  ids  as  they  appear 
in  their  public  key  certificates; 
g  :  the  goods; 

k  :  a  randomly  generated  symmetric  key; 
t  :  transaction  id; 

result,  transferred  :  binary  values  indicating  respectively  whether 

a  transaction  yielded  a  successful  result  and  whether 
any  funds  have  been  transferred. 

Figure  4.1:  The  NetBill  protocol. 

4.1.2  The  protocol 

In  this  subsection,  we  present  the  protocol  itself  (Fig.  4.1).  In  Fig.  4.1,  g  is  the  goods  for  sale, 
and  order  is  a  predefined,  distinguished  message  used  in  goods  requests.  k~x ,  A;"1,  and  k~x  are 
respectively  C,  M,  and  TV’s  private  keys;  and  c  and  m  are  respectively  C’s  and  M’s  ids  as  they 
appear  in  their  public  key  certificates.  We  assume  that  principals  have  cryptographic  capabilities: 
they  can  produce  cryptographic  checksums,  encrypt  and  decrypt  messages,  and  sign  and  verify 
signatures.  We  also  assume  that  C’s  account  always  has  enough  funds;  thus  no  transaction  is 
prevented  from  committing  successfully  because  of  C’s  lack  of  funds. 

To  order  g,  C  sends  order  to  M  (step  1).  Upon  receiving  this  message,  M  starts  the  goods 
delivery  procedure.  To  deliver  g,  M  first  encrypts  it  with  a  randomly  generated  symmetric  key  k, 
and  then  cryptographically  checksums  the  result  of  the  encryption.  M  then  sends  the  encrypted 
goods  enc(g,k),  its  checksum  cc(enc(g ,  k)) ,  and  a  transaction  id  t  to  C  (step  2).  t  is  a  globally 
fresh  id  that  identifies  this  transaction.  Once  C  receives  the  message  sent  by  M,  she  checks 
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whether  the  value  of  the  checksum  is  consistent  with  the  value  of  the  encrypted  goods.  If  so,  C 
prepares  an  electronic  purchase  order  epo,  consisting  of  her  own  id,  the  value  of  the  checksum, 
and  the  transaction  id;  signs  it;  and  sends  it  to  M  (step  3).  At  any  time  before  this  signed  epo  is 
submitted,  C  may  abort  the  transaction  and  be  in  no  danger  of  its  being  completed  against  her 
will.  The  submission  of  this  signed  epo  marks  the  “point  of  no  return”  for  C. 

When  M  receives  this  signed  epo,  he  verifies  whether  both  the  checksum  and  the  transaction 
id  are  the  ones  he  sent  in  step  2.  If  so,  M  prepares  a  transaction  request  tr,  consisting  of  his  own 
id,  the  signed  epo,  and  the  goods  decryption  key;  signs  this  whole  message;  and  submits  it  to  N 
(step  4)  for  final  transaction  processing.  At  any  time  before  this  request  is  submitted  to  N,  M  may 
abort  the  transaction  and  be  in  no  danger  of  its  being  completed  against  his  will.  The  submission 
of  this  request  marks  the  “point  of  no  return”  for  M. 

When  N  receives  a  transaction  request,  N  can  commit  or  abort  the  transaction.  If  N  can  verify 
both  C’s  and  M’s  signatures  on  the  request,  N  commits  the  transaction;  otherwise,  N  aborts  it. 
A  transaction  commit  yields  two  types  of  results,  depending  on  whether  the  request’s  transaction 
id  is  fresh.  If  the  transaction  id  is  fresh,  then  N  transfers  funds  from  C’s  account  to  M’s  account, 
records  the  request,  and  generates  a  signed  slip  attesting  to  a  successful  result.  If  it  is  stale,  N 
only  records  the  request  and  generates  a  signed  slip  attesting  to  an  unsuccessful  result.  A  slip 
consists  of  customer  id,  merchant  id,  transaction  id,  and  two  binary  values  -  result  and  transferred 
-  indicating  respectively  whether  the  transaction  yielded  a  successful  result  and  whether  any  funds 
has  been  transferred.  For  transactions  with  successful  results,  the  decryption  key  is  enclosed.  N 
then  sends  the  slip  to  M  (step  5). 

Upon  receiving  the  slip  from  N ,  M  records  it,  and  forwards  it  to  C  (step  6). 

Intuitively,  having  N  coordinate  transactions  is  critical  to  achieving  all-protection  in  this  pro¬ 
tocol.  If  the  transaction  fails  as  a  result  of  processor  or  communication  failure  before  N  commits 
the  transaction,  then  no  money  changes  hands,  and  C  never  receives  the  decryption  key.  On  the 
other  hand,  if  the  transaction  commits  with  a  successful  result,  then  funds  are  transferred,  and  a 
copy  of  k  is  kept  at  N.  Normally,  a  copy  of  k  is  forwarded  back  to  C  via  M.  But  if  something  goes 
wrong,  C  can  obtain  k  from  N. 

In  the  NetBill  model,  communication  channels  between  different  parties  can  fail.  However,  Ar 
is  assumed  to  be  always  reachable:  it  is  guaranteed  not  to  disappear,  and,  in  the  worst  case,  the 
other  parties  in  the  system  can  reach  it  physically,  off-line.  (For  other  assumptions  about  N,  see 
page  71  -  Trust  Assumptions.)  Because  N  is  always  reachable,  C  and  M  can  always  obtain  the 
slip  from  N,  even  if  it  is  not  received  during  the  normal  message  exchanges  of  the  protocol. 

4.1.3  Our  abstractions 

In  this  subsection,  we  discuss  the  abstractions  we  make. 

•  NetBill  can  be  used  for  selling  both  physical  goods  and  information  goods.  In  both  cases, 
the  customer  expects  something  in  exchange  for  payment:  a  receipt  (needed  to  claim  the 
actual  physical  goods)  or  the  goods  itself.  Henceforth,  we  do  not  distinguish  these  two  cases, 
and  assume  that  the  customer  just  expects  something  -  in  electronic  form  -  in  exchange  for 
payment. 

•  NetBill  was  designed  to  deal  with  several  issues  secondary  to  the  main  exchange.  Some 
examples  are  price  discounts  based  on  membership  in  different  groups,  subscriptions,  and 
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customer  pseudonyms.  In  ‘this  work,  we  abstract  away  all  its  secondary  features  and  focus 
on  the  main  exchange.  These  abstractions  allow  us  to  use  simpler  messages  in  our  version  of 
the  protocol. 

•  In  NetBill,  customers  can  buy  one  or  more  items  that  merchants  have  for  sale,  and  price 
negotiation  phase  can  be  very  elaborate,  taking  multiple  iterations.  Because  we  want  to 
focus  on  exchanges,  we  assume  that  merchants  have  only  one  item  for  sale,  and  everyone 
in  the  system  knows  its  price.  This  allows  us  to  skip  the  price  negotiation  phase  and  start 
the  protocol  with  a  goods  ordering  message.  Our  simplification  does  not  compromise  the 
adequacy  of  our  modeling  or  analyses  because  exchanges  start  only  after  prices  have  been 
agreed  on. 

•  The  original  NetBill  uses  cryptography  to  implement  communication  security.  Given  that 
communication  channels  are  assumed  to  be  secure  in  our  model,  we  can  abstract  away  a 
number  of  cryptographic  operations  in  our  version  of  the  protocol.  Kerberos  tickets,  sym¬ 
metric  key  encryptions,  and  crypto  checksums,  used  for  authenticity,  confidentiality,  and 
integrity  in  the  original  protocol,  are  all  abstracted  away.  The  ones  we  kept  in  our  version  of 
the  protocol  serve  other  purposes  such  as  non-repudiability. 

•  Accounts  in  NetBill  are  credit  or  debit  accounts,  and  need  to  be  balanced  or  replenished. 
Since  the  NetBill  transaction  protocol  does  not  deal  with  these  issues,  we  simply  assume  that 
accounts  have  inexhaustible  funds  or  credits. 

•  For  efficiency,  NetBill  uses  RSA  for  customer  and  merchant  signatures,  and  DSA  for  NetBill 
signatures.  We  abstract  these  details  away  and  model  both  signature  schemes  indistinguishly 
as  an  abstract  public  key  crypto  system  that  has  a  signing  function  and  a  signature  verification 
function  satisfying  the  property  given  in  Def.  4.1  (8). 

•  NetBill  uses  timestamps  to  expire  stale  transactions.  The  notion  of  time  is  relevant  in  defining 
p-protection  because  only  timely  exchanges  matter  in  some  cases.  For  simplicity,  however, 
we  abstract  the  notion  of  transaction  expiration  away  in  our  version  of  the  protocol.  Our 
analysis  results  thus  apply  to  exchanges  that  are  not  time-critical. 

•  We  assume  that  none  of  the  private  keys  have  been  compromised  or  revocated.  This  assump¬ 
tion  allows  us  to  see  signatures  as  expressing  their  signers’  approval,  agreement,  etc. 


4.2  Abstract  Formulation  of  the  Building  Blocks 

4.2.1  Cryptographic  Building  Blocks 

The  NetBill  protocol,  as  introduced  in  Section  4.1.2,  uses  a  number  of  cryptographic  building 
blocks.  In  this  subsection,  we  present  an  abstract  formulation  of  these  building  blocks.  In  what 
follows,  =  denotes  conversion. 

Messages  can  be  encrypted  in  NetBill  using  symmetric  key  encryption.  If  to  is  a  message  and 
k  is  a  symmetric  key,  then 

enc(ro,  k ) 
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denotes  the  encryption  of  m  by  k.  enc  has  a  corresponding  decryption  function  dec.  Given  a 
message  m  and  a  symmetric  key  k, 

dec(m,  k) 

denotes  the  decryption  of  m  by  k.  For  all  encrypted  messages  m!  =  enc (ra,Ar),  and  keys  k ', 
dec(m/,  A:')  =  m,  if  k  —  A/.  That  is, 

dec(enc(m,  A;),  fc)  =  m. 

Messages  can  be  cryptographically  checksummed.  Given  a  message  ra, 

cc(m) 

denotes  m’s  cryptographic  checksum. 

In  public  key  crypto-systems,  private  and  public  keys  come  in  pairs.  If  Ar 1  and  k  are  respectively 
the  private  key  and  the  public  key  of  a  key  pair,  then  they  satisfy  the  predicate  keyPair.  That  is, 

keyPair(A;_1,  Ar)  =  true. 

Messages  can  be  signed  using  public  key  cryptography.  Given  a  message  m  and  a  private  key  Ar-1, 

seal(m,  AT1) 

denotes  the  signature  of  A;”1  on  m.  Signatures  can  be  verified  using  public  keys.  Given  a  message 
m,  a  signature  s,  and  public  key  A;,  the  predicate  vseal  models  signature  verification: 

vseal(m,  $,  k)  =  true 

if  and  only  if  s  is  a  signature  of  A;-1  on  m,  and  A;”1  is  the  private  counterpart  of  k. 

In  Def.  4.1,  we  list  the  cryptographic  building  blocks  as  well  as  their  abstract  properties: 

Definition  4.1  Cryptographic  building  blocks 

1.  Symmetric  keys  have  type  tsymk ,  i.e.,  if  k  is  a  symmetric  key ,  then  k:  tsymk; 

2.  Private  keys  have  type  tjprik,  i.e.,  if  k~l  is  a  private  key ,  then  k~l :  t.prik; 

3.  Public  keys  have  type  t.pubk ,  i.e if  k  is  a  public  key ,  then  k:  tjpubk; 

4.  Cryptographic  checksums  have  type  t.cks,  i.e.,  ifmf  =  cc(m )  for  a  message  m,  then  mf:  Lcks; 

5.  Signatures  have  type  t.seal,  i.e.,  if  m!  =  seal(m ,  k “x)  for  a  message  m  and  a  private  key  k'1 , 
then  m' :  L seal; 

6.  t  is  a  “super-type”,  i.e.,  for  any  message  m,  m  :  t;  ( t  is  called  T  ( “top”)  in  the  subtyping 
literature.) 

Effectively,  we  say  that  a  message  has  type  t  if  we  want  to  look  at  the  message  merely  as  a 
string  of  bits,  and  not  as  a  structured  message.  For  example,  in  an  encryption,  it  is  irrelevant 
whether  the  message  being  encrypted  is  an  integer,  a  key,  or  a  meaningless  string  of  bits. 

7.  Functions  and  predicates: 
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•  enc:  t  x  t.symk  — »  t; 

•  dec:  t  X  t.symk  —>■  t; 

•  cc:  £  — >•  t.cks; 

•  keyPair:  t.prik  X  t.pubk  — >  boolean; 

•  seal:  t  X  t.prik  t.seal; 

•  i weal:  t  x  t.seal  x  t.pubk  — >  boolean; 

8.  Conversion  rules : 

•  V  m:  t,  k:  t.symk,  kf :  t.symk,  dec(enc(m,  k),  k)  =  m,  if  and  only  if  k  —  k! ; 

f  true ,  i/3  fc_1;  tjprik  \  s  =  seal(m,  fc_1)  A  fceyPair(fc_1,  A;); 

•  vseanra, s. «)  =  <  r  7  ^  7 

v  /  I  false ,  otherwise . 

4.2.2  Product  Types  and  Projection  Functions 

The  types  that  appear  in  Subsection  4.2.1  define  messages  required  and  produced  by  cryptographic 
functions.  Other  types  of  basic  messages  used  in  NetBill  are  t.pid ,  for  principal  ids;  and  t.tid,  for 
transaction  ids. 

Some  concatenated  messages  have  special  semantics  in  NetBill.  For  conciseness,  we  name 
their  corresponding  product  types,  and  define  projection  functions  for  these  types.  For  example, 
certificates  consist  of  two  components:  a  principal  id  and  a  public  key,  and  have  type  t.pid  X 
t.pubk.  For  conciseness,  we  denote  the  product  type  t.pid  x  t.pubk  by  t.cert: 


t.cert  —  t.pid  X  t.pubk. 

For  extracting  the  components  of  a  certificate,  we  define  projection  functions  pid  and  key.  pid 
returns  the  principal  id,  while  key  returns  the  public  key: 


If  m  —  mim2  has  type  t.cert ,  then 


id(m)  =  mi,  and 
key(m)  =  m2 


We  list  the  product  types  and  their  corresponding  projection  functions  below. 


Certificates:  t.cert  =  t.pid  X  t.pubk 

If  m  =  mim2  has  type  t.cert ,  then 


id(m)  =  mi,  and 
key(m)  =  m2. 


Epos:  t.epo  =  t.pid  X  t.cks  X  t.tid 

If  m  —  mim2m3  has  type  t.epo,  then 


cid(m)  =  mi, 

<  cks(m)  =  m2,  and 
tid(m)  =  m3. 


Signed  epos:  t.sepo  =  t.epo  X  t.seal 

If  m  —  mim2  has  type  t.sepo ,  then 


msg(m)  =  mi,  and 
sig(m)  =  m2. 
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Transaction  requests:  t.tr  =  t.pid  x  t.sepo  x  tsymk 

mid(m)  =  mi, 

If  m  =  mim'2m3  has  type  t.tr,  then  <  sepo(m)  =  m2,  and 

key(m)  =  m3. 

Signed  transaction  requests:  t.str  =  t.tr  X  t.sea.1 
If  m  =  mim2 


has  type  Ls<r,  then  {  msS(7?1)  771-1  ’  an<^ 

[  sig(m)  =  m2. 


Transaction  slips:  Ls/fp  -  boolean  x  t.pid  X  t.pid  x  boolean  x  t.symk  x  t.tid 

res  (m)  =  raj, 


If  m  =  mim2m3m4m5m6  has  type  tslip,  then  < 


cid(m)  =  m2, 
mid(m)  =  m3, 
trans(m)  =  m4, 
key(m)  =  m5,  and 
(  tid(m)  =  m6- 


Signed  transaction  slips:  t.sslip  =  t.slip  x  Lseo./ 

msg(m)  =  mi,  and 


If  m  =  mim2  has  type  t.sslip,  then 


sig(m)  =  m2. 


Note  that  some  projection  functions  are  overloaded.  For  example,  msg  can  be  applied  to 
messages  of  types  t.sepo,  s.str,  and  t.sslip;  and  tid  can  be  applied  to  messages  of  types  t.epo  and 
t.slip. 

For  readability,  we  syntactically  distinguish  applications  of  cryptographic  functions  and  projec¬ 
tion  functions.  Applications  of  cryptographic  functions  are  denoted  in  a  standard  way:  f(ai,  ...,an), 
where  /  is  the  function  and  a,-,  i  =  1, . .  .,n,  are  the  arguments.  Applications  of  projection  func¬ 
tions,  on  the  other  hand,  are  denoted  as  a.f,  where  a  is  the  argument  and  /  is  the  function.  For 
example,  if  m  is  a  certificate,  then  we  use  cc(m)  to  denote  m’s  checksum,  and  m.key  to  denote  m’s 
public  key  component. 


4.3  Formalizing  the  Protocol  and  the  Protection  Properties 

In  this  section,  we  specify  the  NetBill  protocol  using  our  specification  formalism  (Section  2.3),  and 
give  concrete  specifications  of  protection  properties  as  applied  to  this  protocol. 

4.3.1  Protocol  Specification 

Principals  of  the  Protocol 

V  =  {C,  M ,  N) 

Initial  Conditions 

Let  k~1,  and  k~1  be  respectively  C,  M,  and  N's  private  keys;  Kn  be  TV’s  public  key;  tc  and 
Lm,  and  4>c  and  <j>m  be  respectively  C’s  and  M’s  ids  and  public  key  certificates.  Also,  let  7  be  the 
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goods  for  sale,  and  0  be  the  set  of  stale  transaction  ids.  The  initial  condition 

X  =  shareable}/?"1,  {C})  A  shareable}*"1,  {M})  A  shareable}*;1,  {N})  A  shareable^,  {M})  A 
keyPair}*;1,  <£c.key)  A  keyPair}*"1,  <£m.key)  A  keyPair}*;1,  *„)  A 
ic  =  <t>c- id  Aim  —  4>m-id  A 

K'VJ  c  MSC  A  {k^1,  im,  0, 7}  C  MSm  A  {k*1 ,4>c,  4>m,  0}  c  MS“ 

says  that  all  principals  have  their  own  private  keys;  N  has  both  C  and  M’s  certificates;  M  has  the 
goods,  and  M  and  N  have  consistent  views  of  which  transaction  ids  are  stale.  Note  that  this  last 
condition  only  holds  because  our  system  has  only  one  merchant. 

Local  Protocols 

In  what  follows,  w,  x,  y,  z  are  variables;  identifiers  in  Small  Cap  are  constants;  and  those  in  slanted 
fonts  are  placeholders  for  more  complex  messages.  The  constants  that  appear  below  are  Order, 
which  denotes  the  predefined  message  used  in  goods  requests;  True  and  False;  and  Null,  which 
indicates  the  absence  of  messages. 

In  the  specification  below,  we  need  two  types  of  events  not  listed  in  Section  2.2.2:  new(x ,  y ) 
and  commit(x,y).  We  use  new(*,y)  to  model  generation  of  elements  y  not  found  in  the  set  x.  In 
the  context  of  NetBill,  new(0,  $)  models  the  generation  of  a  fresh  transaction  id  6 ,  different  from 
all  those  found  in  0,  the  set  of  stale  transaction  ids.  And  any  message  (epos,  transaction  requests, 
transaction  slips,  etc)  that  encloses  a  fresh  transaction  id  is  also  fresh. 

Commit}*,  y)  is  used  to  model  transaction  commits.  In  our  model,  two  messages  are  generated 
with  each  transaction  commit:  a  transaction  slip  and  a  transaction  request.  They  appear  respec¬ 
tively  as  arguments  x  and  y  in  commit  events.  We  assume  that  these  messages  are  retained  at 
N,  and  are  promptly  made  available  to  arbitrators  and  parties  involved  in  the  transaction  upon 
request. 

Next  we  present  the  local  protocols. 

C s  local  protocol  Tic  consists  of  the  following  rules: 

RCl :  send(M,  Order)  £  H  =>  {send(M,  Order),  exit} 

Rc2:  last(H)  =  send(M,  Order)  =*>  { receive (M,  x  :  t  x  t-cks  x  tJid),  timeout,  exit} 

RCz:  3*i  :  t,x 2  :  t.cks,x 3  :  tJid  \  last(H)  =  receive (M,  x  1  x2  *3)  A  cc(*i)  =  x2  =P 
{send(M,  epo  seal (epo,  kJ1)),  exit}, 

where:  epo  =  ic  x2  *3. 

RCi:  3x  :  t.sepo  \  last(H)  =  send(M,a:)  {receive(M,y  :  tsslip ),  timeout} 

RCi :  (3*i  :t,x 2  :  t.cks,x 3  :  tJid  |  (last(H)  =  receive(M,*i  x2  x3)  A  cc(*i)  ^  x2)  V 
last(H)  =  timeout  V  3y  :  tsslip  |  last(H)  =  receive(M,y)  {exit} 

M’s  local  protocol  7 Im  consists  of  the  following  rules: 

RMl:  receive(C,  Order)  ^  H  =>  {receive(C,  Order),  timeout,  exit} 

Rm2>  receive(C,  Order)  G  H  A  (fix  :  tsymk  \  random}*)  G  H)  {random(y  :  tsymk ),  exit} 


69 


RMi‘  receive (C,  Order)  g  H  A  {fix  :  tJid  |  new(0,a)  G  H)  =>  {new(0,y  :  tJtid),  exit} 

Rm4:  3a-  :  t.tid  \  new(0,a)  G  H  A  3y  :  tsymk  |  random(y)  €  H  A 

{fiz  :  t  x  t.cks  X  t.tid  |  send  {C,  z)  €  H)  A  last(H)  timeout  => 

{send(C,  eg  cc(eg)  x),  timeout,  exit}, 

where  eg  =  enc(y,y ) 

Rm5:  3  x  :t  X  t.cks  X  tJ-id  |  last(H)  =  send(C,  x)  =$>  {receive(C,  y  :  tsepo ),  timeout,  exit} 

Rm6:  3x  :  tsepo,  yi  y2  yz'.tx  t.cks  x  t.tid,  z:  tsymk  \ 

last(H)  =  receive(C,  x)  A  send(C,  yi  y2  y3)  G  H  A  y2  =  a.msg.cks  A  y3  =  a.msg.tid  A 
random (2)  G  H  =>  {send(JV,  trseq  seal {tr.req,  k'1)),  exit} 

where  trseq  =  tm  x  z 

Rm-j *  3a  :  tstr  |  last(H)  =  send(iV,  x)  =>•  {rece\ve{N,y  :  tsslip),  timeout} 

Rms’  3a  :  tsslip  |  last(H)  =  receive}^,  a)  =*>  {send(C,  a),  timeout} 

Rm9 •  last(H)  =  timeout  V  3z  :  tsslip  |  last(H)  =  send(C,  z)  V 
3a  :  tsepo,  yi  y2  y3  :  t  x  t.cks  x  t.tid  \ 

(last(H)  =  receive  (C,  a)  A  send(C,yi  Vi  y3)  G  H  A  (y2  a.msg.cks  V  y3  ^  a.msg.tid))  => 
{exit} 

N's  local  protocol  7Z jv  consists  of  the  following  rules: 

RNi-  fix  :  tstr  |  receive(M,  a)  G  H  =>  {receive(M,  y  :  t.str)} 

Rn2  :  3x  :  tstr,  3 y  :  t.prik  \ 

last(H)  =  receive(M,  a)  A  a.msg.sepo.msg.tid  ^  0  A 
a.msg.mid  =  <^TO.id  A  vseal(a.msg,  a.sig,  4>m. key)  A 

a.msg.sepo.msg.cid  =  <f>c. id  A  vseal(a.msg.sepo.msg,  a.msg.sepo.sig,  <^>c.key)  A 
y  =  k"1  A  y  G  MS"  =>  {commit(sf/p  seal  {slip,  y),  a)}, 

where:  slip  =  True  a.msg.sepo.msg.cid  a.msg.mid  True  a.msg.key  a.msg.sepo.msg.tid 

Rn3  :  3a  :  tstr,  3 y  :  t.prik  | 

last(H)  =  recei ve(M,  a)  A  a.msg.sepo.msg.tid  G  0  A 
a.msg.mid  =  <^TO.id  A  vseal(a.msg,  a.sig,  <?i>TO.key)  A 

a.msg.sepo.msg.cid  =  </>c.id  A  vseal(a.msg.sepo.msg,  a.msg.sepo.sig,  <^>c.key)  A 
V  ~  ^n1  A  y  G  MS"  =>  {commit(shp  seal  {slip,  y),  a)}, 

where:  slip  =  False  a.msg.sepo.msg.cid  a.msg.mid  False  Null  a.msg.sepo.msg.tid 

Rn4-  3x  :  tsslip,  y  :  tstr  |  last(H)  =  commit(a,y)  =>  send(M,  a) 

Rn*,‘  3a  :  tstr  |  (last(H)  =  receive(M,  a)  A 

-i  (a.msg.mid  =  <^>m.id  A  vsea.l(a.msg,  a.sig,  <^>m.key)  A 

a.msg.sepo.msg.cid  =  <f>c.\d  A  vseal(a.msg.sepo.msg,  a.msg.sepo.sig,  </>c.key)))  V 
3y  :  tsslip  |  last(H)  =  send(M,  y)  =*>  {exit} 
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Note  that,  in  our  specification,  N  does  not  process  a  transaction  request  unless  it  can  verify  both 
C  and  M’s  signatures  (Rn&).  If  both  signatures  can  be  verified,  then  N  commits  the  transaction, 
generates  a  slip  (Rn2  and  Rn3),  and  sends  it  to  M  (Rn4)-  A  transaction  can  be  committed  with 
a  successful  result  ( Rn2 )  or  with  an  unsuccessful  one  ( Rn3 ).  The  content  of  the  slip  indicates  it. 

Trust  Assumptions 

In  this  subsection,  we  specify  a  set  of  trust  assumptions  for  NetBill.  Unlike  the  intermediary  in 
FR’s  protocol,  the  intermediary  here  -  the  NetBill  server  -  is  assumed  to  be  completely  trusted, 
i.e.,  is  expected  to  behave  exactly  as  prescribed  by  the  protocol.  However,  servers  can  fail  and 
communication  links  can  go  down,  and  trusted  servers  may  in  fact  exhibit  deviant  executions. 
When  justifying  why  the  NetBill  server  keeps  cryptographically  signed  messages,  Tygar  himself 
says  [84] 

“Many  electronic  commerce  systems  depend  on  some  ultimate,  trusted  authority.  For 
example,  NetBill  depends  on  the  trustworthiness  of  a  central  server.  However,  even  in 
the  case  where  one  uses  a  trusted  server,  one  can  minimize  the  effects  of  the  security 
failures  of  that  server.  For  example,  in  NetBill,  detailed  cryptographically-unforgeable 
records  are  kept  so  that  if  the  central  server  was  ever  corrupted,  it  would  be  possible 
to  unwind  all  corrupted  actions  and  restore  any  lost  money.” 

Thus,  the  trust  assumptions  we  list  below  were  not  given  explicitly  by  the  authors  of  the 
protocol;  instead,  we  inferred  them  from  informal  discussions  [84]  about  how  NetBill  guarantees 
goods  atomicity  and  certified  delivery,  and  how  disputes  are  settled  off-line.  By  giving  this  set  of 
trust  assumptions,  we  are  implicitly  saying  that  NetBill  can  be  all-protective  even  if  the  NetBill 
server  does  not  behave  compliantly;  all-protection  is  guaranteed  as  long  as  the  following  trust 
assumptions  are  not  violated. 

In  what  follows,  we  first  list  informal  statements  of  these  trust  assumptions;  we  then  specify 
them  formally. 

In  NetBill,  neither  C  nor  M  is  trusted.  Thus,  Tc  =  true  and  TM  =  true.  N  is  trusted.  It  is 
trusted: 

•  Tty:  To  transfer  funds  only  if  the  transaction  commits; 

•  T/v2:  To  release  the  key  submitted  by  M  only  if  the  transaction  commits; 

•  Tn3-  To  sign  slips  made  available  by  transaction  commits. 

•  T/v4  :  Not  to  produce  signed  slips  with  corrupted  merchant  ids;  and 

•  TN5 :  To  send  M  only  slips  made  available  by  transaction  commits. 

We  proceed  with  formalizations  of  these  trust  assumptions. 

T^i  and  Tn2  always  hold  in  our  model,  and  therefore  do  not  need  additional  specification.  T/v, 
always  holds  in  our  model  because  we  do  not  model  funds  transfers  explicitly.  Their  occurrences  are 
reflected  in  transaction  slips  generated  when  transactions  commit.  True  in  a  slip’s  ‘transferred’  field 
indicates  that  the  corresponding  transaction  transferred  funds.  Given  that  slips  are  generated  only 
when  transactions  commit,  we  conclude  that  funds  transfers  only  occur  when  transactions  commit. 
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This  restriction  is  not  serious  because  even  though  funds  may  be  transferred  independently  of  slip 
generations  and  transaction  processings  in  reality,  such  transfers  are  sure  to  be  disputed  and  voided. 

Similarly,  T/v2  always  holds  in  our  model  because  keys  are  released  only  through  transaction 
slips,  which  are  generated  when  transactions  commit. 

Tjv3:  Vx:  t.sslip ,  □  (commit(a:,  — *)  €  H  — f  vseal(ar.msg,  z.sig,  k„)) 

In  T/\q ,  non-corrupted  customer  ids,  merchant  ids,  and  transaction  ids  mean  those  originating 
from  transaction  requests: 

T]\[4 :  V,r:  t.sslip , 

□  (commit(a;,  — )  €  H  — >  (3 2  :  t.str  |  receive(M,  z)  6  H  A  x.msg.mid  =  z.msg.mid)) 

Tjy5:  \fx:  t.sslip,  □  (send(M,:r)  6  H  ->  commit(a:,-)  €  H) 

In  Sections  4.4  and  4.5,  we  show  how  protection  of  individuals’  interests  can  be  compromised 
if  these  trust  assumptions  are  violated  in  the  system. 

4.3.2  Specification  of  Protection  Properties 

In  this  subsection,  we  formally  specify  both  C’s  and  M’s  protection  properties  in  the  context  of 
NetBill.  Unlike  in  FR’s  protocol,  where  exchanges  take  place  entirely  on-line,  here  exchanges  may 
start  on-line  and  finish  with  dispute  resolutions  off-line.  That  is,  participants  in  NetBill  may  not 
receive  what  they  are  supposed  to  during  a  protocol  execution.  The  certified  delivery  mechanisms, 
however,  enables  them  to  take  proofs  of  what  really  happened  on-line  to  an  off-line  arbitrator,  and 
claim  what  they  are  entitled  to.  This  makes  the  concept  of  “receiving  an  item”  (goods  or  payment) 
less  clear-cut  here  than  in  FR’s  protocol. 

Preliminaries 

Before  plunging  into  formalizations,  we  characterize  a  number  of  execution  outcomes  relevant  to 
the  specification  of  protection  properties.  For  the  specification  of  protection  properties,  relevant 
outcomes  are  those  where  C  is  guaranteed  the  goods  or  M  is  guaranteed  a  payment.  C  is  guaranteed 
the  goods  if  and  only  if 

Cl:  she  actually  receives  the  goods  during  the  protocol  execution,  or 
C 2:  she  can  claim  the  goods  in  court. 

M  is  guaranteed  a  payment  if  and  only  if 

Ml:  he  has  proof  that  C  received  the  goods,  or 

M2:  he  has  proof  that  N  committed  the  transaction  a)  with  a  successful  result,  and  b) 
and  did  so  in  response  to  a  valid  request. 

Note  that  for  M,  it  is  irrelevant  whether  funds  are  actually  transferred  during  the  transaction 
processing.  What  really  matters  is  whether  he  is  entitled  to  a  payment  (Conditions  Ml  and  M2 
make  him  entitled  to  a  payment).  For  example,  if  funds  are  mistakenly  transferred  from  C’s  account 

'We  use  to  stand  for  messages  whose  actual  values  are  irrelevant  in  the  context. 
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to  M’s  account  during  a  transaction  processing,  C  will  certainly  dispute  the  debit,  and  the  transfer 
will  certainly  be  voided.  On  the  other  hand,  if  M  is  entitled  to  a  payment,  but  no  funds  are 
transferred  during  the  transaction  processing,  then  M  can  claim  it  later. 

Before  detailing  each  of  the  conditions  above,  we  clarify  the  meanings  of  a  few  expressions 
used  below:  N  makes  a  message  “publicly”  available ;  C  ( M )  has  access  to  a  message ;  an  epo 
and  a  transaction  slip  correspond  to  each  other,  and  a  transaction  request  and  a  transaction  slip 
correspond  to  each  other. 

As  a  transaction  coordinator  and  the  trusted  party  of  NetBill  transactions,  N  is  entrusted 
to  keep  a  number  of  messages,  and  to  make  them  available  to  selected  parties.  For  example, 
transaction  slips  can  be  made  available  to  the  arbitrator  and  the  parties  involved  in  the  transaction 
-  C  and  M,  but  no  one  else.  For  conciseness,  we  use  N  makes  a  message  “publicly”  available  to 
mean  N  makes  a  message  available  to  the  appropriate  group  of  selected  parties. 

Related  to  the  concept  above  is  the  concept  of  accessibility  of  messages.  We  say  that  C  ( M )  has 
access  to  a  message  if  C  (M)  has  the  message  in  his  or  her  local  store,  or  N  has  made  it  “publicly” 
available. 

Finally,  we  say  that  an  epo  and  a  transaction  slip  corresponds  to  each  other  if  they  have  the 
same  customer  id  and  transaction  id;  and  a  transaction  request  and  a  transaction  slip  correspond 
to  each  other  if  they  have  the  same  customer  id,  merchant  id,  and  transaction  id. 

We  now  characterize  the  four  conditions  listed  above.  For  conciseness,  we  say  that  a  transaction 
request  is  valid  if  it  is  signed  by  both  C  and  M,  and  its  transaction  id  is  fresh. 

Cl:  C  actually  receives  the  goods  g  during  the  protocol  execution  if  and  only  if: 

•  C  receives  a  message  mi  m2  m3:  t  X  t-cks  X  tJtid  with  encrypted  goods  mi; 

•  C  has  access  to  a  transaction  slip  m 4,  whose  transaction  id  is  m3;  and 

•  dec(mi,  m4.msg.key)  =  g. 

In  other  words,  C  actually  receives  the  goods  if  and  only  if  C  receives  an  encrypted  message 
and  a  key,  and  the  goods  can  be  obtained  by  decrypting  the  encrypted  message  with  the  key. 

C2:  C  can  claim  g  in  court  if  and  only  if 

•  C  receives  a  message  mi  m2  m3:  t  X  t-cks  X  tJid  with  encrypted  goods  mi; 

•  C  has  access  to  a  fresh  /V-signed  transaction  slip  m4  satisfying  the  following  conditions: 
m4’s  transaction  id  is  m3,  and  m4  attests  to  a  transaction  that  yielded  a  successful 
result; 

•  N  makes  a  valid  m4-corresponding  transaction  request  m5  “publicly”  available;  and 

•  The  value  of  mi  is  consistent  with  the  checksum  enclosed  in  ms,  but  decrypting  it  with 
the  key  enclosed  in  m 4  yields  something  other  than  g. 

tv,  •  /  cc(TOi)  =  m5.msg.sep0.msg.cks  A 

at  1S’  |  dec(mi,  m4.msg.key)  ^  g. 

Intuitively,  C  can  claim  g  in  court  if  C  can  show  that  the  transaction  was  successfully  pro¬ 
cessed  by  N  in  response  to  a  valid  request,  but  the  goods  cannot  be  retrieved  from  the 
decryption  key  released  in  the  transaction  slip  and  the  encrypted  message  given  by  M. 
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Ml:  M  has  proof  that  C  received  the  goods  g  if  and  only  if 

•  M  received  a  C-signed  epo  mx  -  with  a  fresh  transaction  id  -  from  C; 

•  M  has  access  to  a  mi-corresponding,  N- signed  transaction  slip  m2;  and 

•  encrypting  g  with  the  key  released  in  m2  (m2.msg.key)  yields  an  encryption  whose 
checksum  is  consistent  with  the  checksum  enclosed  in  mi  (mi.msg.cks).  That  is 

cc(enc(<jr,  m2.msg.key))  =  mi.msg.cks. 

The  three  conditions  above  prove  that  C  received  g  because  1)  the  existence  of  mj  proves 
that  C  received  an  encrypted  message;  2)  the  existence  of  rn2  proves  that  C  can  access  the 
key  released  by  N;  and  3)  the  checksum  test  proves  that  g  is  retrievable  from  the  encrypted 
message  and  the  released  key. 

M2:  M  has  proof  that  N  committed  the  transaction  a)  with  a  successful  result,  and  b)  and  did  so 
in  response  to  a  valid  fresh  request  if  and  only  if 

•  M  has  access  to  a.  fresh  iV-signed  transaction  slip  mx  attesting  to  a  transaction  that 
yielded  a  successful  result;  and 

•  N  makes  a  valid  mi-corresponding  transaction  request  m2  “publicly”  available. 

Note  that  C  may  or  may  not  have  received  the  goods  on-line  under  these  conditions.  If  C 
received  the  goods  on-line,  then  M  is  clearly  entitled  to  a  payment.  Otherwise,  M  should 
still  be  entitled  to  it,  because  C  can  claim  the  goods  in  court. 

Formalization 

We  now  use  the  conditions  we  just  characterized  to  define  protection  properties  for  different  parties 
in  NetBill.  C’s  protection  property  Pq  says  that 

“If  M  is  entitled  to  a  payment,  then  C  actually  receives  the  goods,  or  C  can  claim  it 
in  court”; 

and  M’s  protection  property  Pm  says  that 

“If  C  actually  receives  the  goods,  or  C  can  claim  it  in  court,  then  M  is  entitled  to  a 
payment.” 

Pc  and  Pm  can  be  respectively  formalized  as  follows: 

Pc  ■  — 4  □(($Ml  V  $M2)  — >•  0($ci  V  $C2))i 


and 

Pm  ■  db  — *■  □(($ci  V  d>c2)  — ►  V  $Af2))) 

where 

=  Vx  :  tJid ,  (3y  :  t  \  ( y  e*  MSm  V  y  £*  MSN)  A  xCy)-»xe0 
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$A/i  =  '•  tsepo ,  y  :  tsslip  \ 

(receive(C,  x )  G  HMA  ar.msg.tid  ^0  A 
z.msg.cid  =  4>c. id  A  vseal(ar.msg,  ar.sig,  <£c.key)A 

(receive^,  y)  €  HMV  commit(y,  -)  G  Hw)  A  vseal(y.msg,  y. sig,  nn)  A 
y.msg.mid  =  <f)m.id  A  x.msg.cid  =  y.msg.cid  A  ar.msg.tid  =  y.msg.tid  A 
cc(enc(7,  y.msg.key))  =  x.msg.cks), 

$M2  —  3a;  :  tsslip,  y  :  tstr  \ 

(receive^,  x)  G  HMV  commit(a;,  y)  G  HN)  A  x.msg.mid  =  <^>m.id  A 
vseal(a;.msg,  z.sig,  nn)  A  z.msg.res  A  x.msg.tid  £  0  A 
ai.msg.tid  =  y.msg.sepo.msg.tid  A 

ar.msg.mid  =  y.msg.mid  A  ar.msg.cid  =  y.msg.sepo.msg.cid  A 
y.msg.mid  =  (j>m. id  A  y.msg.sepo.msg.cid  =  4>c. idA 

vseal(y.msg,  y.sig,  <f>m.key)  A  vseal(y.msg.sepo.msg,  y.msg.sepo.sig,  <£c.key) 

$ci  =  3xi  x2  xz  :  t  x  t.cks  x  tJtid,  y\  :  tsslip  | 
recei ve(M,  xi  x 2  x3)  G  HCA 

((receive(M,  3/1)  G  Hc  A  yi.msg.tid  =  x3  A  dec(zi,  yi.msg.key)  =  7)V 
(commit(j/i,  -2)  G  HN  A  yi.msg.cid  =  4>c. id  A  yi.msg.tid  =  ar3A 
dec(a;1,yi.msg.key)  =  7)), 

$C2  =  3a;i  x2  x3:t  X  tsks  X  tJid ,  y  :  tsslip,  z  :  tstr  \ 

receive(M,  *1  £2  a;3)  G  HCA 
(receive(M,  y)  G  HCV  commit(y,  z)  G  HH)  A 
vseal(y.msg,  y.sig,  Kn)  A  y.msg.res  A  y.msg.tid  ^  0  A 
y.msg.cid  =  <f)c. id  A  y.msg.tid  =  ai3A 
y.msg.tid  =  2r.msg.sep0.msg.tidA 

y.msg.mid  =  2r.msg.mid  A  y.msg.cid  =  2r.msg.sep0.msg.cid  A 
2r.msg.mid  =  <£TO.id  A  2r.msg.sep0.msg.cid  =  <£c.idA 

vseal(2r.msg,  2r.sig,  <£m.key)  A  vseal(2r.msg.sepo.msg,  2r.msg.sep0.sig,  <£c.key)  A 
cc(a;i)  =  2r. msg.sepo.msg.cks  A  dec(a;i,  y.msg.key)  ^  7. 

A  few  comments  about  the  formalization  are  in  place  here.  First,  we  assume  for  both  Pc 
and  Pm-  specifies  that  neither  M  nor  N  has  fresh  transaction  ids  at  the  beginning  of  protocol 
executions.  Assuming  <$>;  allows  us  to  focus  on  scenarios  where  no  unresolved  transactions  are 
pending. 

$Afi)  $ci,  and  $C2  respectively  formalize  conditions  Ml,  M2,  Cl,  and  C 2. 

Finally,  transaction  slips  retained  at  N  are  accessible  only  to  arbitrators  and  principals  involved 
in  the  corresponding  transactions.  Thus,  C  (M)  can  access  a  transaction  slip  mf  retained  at  N 
only  if  mi  indicates  C  (M)  as  the  customer  (merchant)  of  the  transaction.  In  the  formalization 
above,  we  model  “mj  is  accessible  to  C”  and  “mi  is  accessible  to  M”  by  mi.msg.cid  =  <f>c. id  and 
mi.msg.mid  =  ^m.id  respectively.  These  accessibility  conditions  do  not  apply  if  a  slip  is  received 
by  C  or  M  during  a  protocol  execution;  in  our  model,  principals  can  always  access  messages  they 
receive.  This  difference  is  illustrated  in  $ci,  where  we  require  the  equality  yi.msg.cid  =  4>c. id  to 
hold  only  if  yi  is  the  copy  retained  at  N. 
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4.4  Analysis  of  the  Protocol 

In  this  section,  we  analyze  the  NetBill  protocol  under  all  three  deviation  modes  defined  in  Sec¬ 
tion  2.4.3.  Subsections  4.4.2,  4.4.3,  and  4.4.4  have  respectively  analyses  of  the  protocol  under 
deception,  compliance,  and  abortion  modes.  Subsection  4.4.1  has  some  preliminaries. 

The  proof  strategy  used  here  differs  from  the  one  used  for  Franklin  and  Reiter’s  protocol.  To 
analyze  Franklin  and  Reiter’s  protocol,  we  resorted  to  protocol  rules  whenever  possible;  trust  as¬ 
sumptions  were  used  only  when  principals  may  behave  non-compliantly.  Thus,  we  had  different 
proofs  for  compliant  and  deviant  executions.  To  analyze  NetBill,  we  mainly  resort  to  trust  assump¬ 
tions.  Under  this  approach,  we  first  prove  that  trustworthy  executions  satisfy  our  target  properties; 
then  we  argue  that  maximal  compliant  executions  also  do,  because  they  are  trustworthy.  This  proof 
strategy  is  interesting  because  it  allows  us  to  use  the  same  proof  for  both  compliant  and  deviant  - 
but  trustworthy  -  executions. 

In  this  section,  we  present  only  the  main  results  and  their  high-level  analysis.  For  completeness, 
detailed  proofs  appear  in  Section  4.5. 

4.4.1  Preliminaries 

In  this  subsection,  we  present  two  results  needed  in  the  rest  of  the  analysis.  Lemma  4.2  says  that, 
in  NetBill,  each  protocol  step  gets  instantiated  at  most  once  in  executions  we  consider.  Its  proof 
is  straightforward,  and  depends  on  the  fact  that  the  protocol  rules  either  have  enabling  conditions 
that  prevent  same  types  of  events  from  occurring  more  than  once,  or  can  be  enabled  only  once,  by 
an  occurrence  of  an  event  that  cannot  occur  more  than  once. 

Lemma  4.2  Let  II  be  the  NetBill  protocol,  a  be  an  execution  in  E{U)C  U  ^(II)^  U  £'(n)'D)  e,-  be 
an  event  in  a,  and  E  be  an  event-template  prescribing  a  protocol  step  in  II.  If  e,-  is  an  instance  of 
E,  then  there  does  not  exist  ej  in  a ,  i  ^  j ,  such  that  ej  is  also  an  instance  of  E. 

Theorem  4.3  says  that  all  maximal  compliant  executions  of  NetBill  are  trustworthy. 

Theorem  4.3  Let  II  be  the  NetBill  protocol  and  T  be  its  trust  assumptions.  Then 

V<t  G  E{U)C ,  (7  f=*  r. 

Proof:  Given  that  N  is  the  only  trusted  party,  T  =  7jv  =  {T/v3,  T/v4>  Iat5} ,  and  this  theorem 
follows  from  Lemmas  4.4,  4.5,  and  4.6. 

□ 

Lemma  4.4  Let  n  be  the  NetBill  protocol  and  7/v  =  {T/v3,  Tj\[4)Tn5}  be  the  trust  assumptions  we 
make  of  N  (as  specified  in  Section  f.S.l).  Then 

V<rG£(n)c,  a\=*TN3. 
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Lemma  4.5  Let  II  be  the  NetBill  protocol  and  Tn  =  {Tn3  ,  Tff4 ,  Tn5 }  be  the  trust  assumptions  we 
make  of  N  (as  specified  in  Section  4-3.1)-  Then 

VoeE(Tl)c ,  a  I =*TNi. 


Lemma  4.6  Let  II  be  the  NetBill  protocol  and  Tn  =  {Tn3,Tn4,Tn5}  be  the  trust  assumptions  we 
make  of  N  (as  specified  in  Section  4-3.1).  Then 

Vo-  €  E(U)C,  o  K  TNs. 

4.4.2  Protection  under  Deception  Mode 

In  this  subsection,  we  analyze  the  protocol  under  deception  mode.  We  first  analyze  it  with  respect 
to  C- protection,  then  with  respect  to  M-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  to  analyze  the  protocol  with  respect  to  C- 
protection  under  deception  mode,  we  need  to  analyze  all  executions  in  E(Yl)c  and  trustworthy 
executions  in  E( II)®.  We  do  so  in  Prop.  4.10  and  4.7  respectively. 

Proposition  4.7  Let  II  be  the  NetBill  protocol,  o  be  an  execution  in  E(Ti)%,  T  be  the  trust  as¬ 
sumptions  II  makes,  and  Pc  =  -4  □(($mi  V  $a«)  -4  0($ci  V  $02))  be  C ’s  protection  property 

as  specified  in  Section  4-3.2.  Then 


a  |=*  T  implies  0  (=*  Pc- 


Proof: 

1.  Let  a  =  Sq  e\  s\  ...  be  a  trustworthy  execution  such  that  so  \=  We  need  to  prove  that 
a  |=*  n($Mi  V  4>m2  —1  0(*ci  v  $02))- 

2.  According  to  Lemma  4.8,  a  {=*  D($mi  -4  0$ci);  and  according  to  Lemma  4.9, 
o  |=*  D($M2  — *  0(4>ci  V  $02))- 


□ 

Bearing  in  mind  what  4>mi5  $M2,  and  $C2  specify  (Section  4.3.2),  the  proof  of  Prop.  4.7 
shows  that  if  M  has  proof  that  C  received  the  goods  -  and  is  therefore  entitled  to  a  payment,  then 
C  actually  received  the  goods  (Lemma  4.8);  and  if  M  has  proof  that  N  committed  the  transaction 
with  a  successful  result,  and  did  so  in  response  to  a  valid  request  -  and  is  therefore  entitled  to  a 
payment,  then  C  actually  received  the  goods  or  C  can  claim  it  in  court  (Lemma  4.9). 

Lemma  4.8  Let  II  be  NetBill  protocol,  o  be  an  execution  in  E(U)q,  T  be  the  trust  assumptions  II 
makes,  and  Pc  =  -4  □(($mi  V  $m2)  -4  0($ci  V  $02))  be  C’s  protection  property  as  specified 

in  Section  4-3.2.  Then 


o  \=*  T  implies  a  |=*  □($jwi  -4  O^Ci)- 
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Lemma  4.9  Let  II  be  NetBill  protocol,  a  be  an  execution  in  E(X\)q,  T  be  the  trust  assumptions  II 
makes,  and  Pc  =  — *  Q((4>a/i  V  $>M2)  ~4  ^($ci  V  $C2))  be  C’s  protection  property  as  specified 
in  Section  4-3.2.  Then 

o\=*  T  implies  a  \=*  $t-  ->■  □  ($^2  -4  0(4>ci  V  $02))- 

Prop.  4.10  concerns  maximal  compliant  executions.  These  executions  are  trustworthy  and  have 
compliant  local  executions  of  C.  Given  that  our  proof  for  Prop.  4.7  relies  on  the  fact  that  o  is 
trustworthy  and  has  a  compliant  local  execution  of  C,  it  can  be  used  as  is  to  prove  Prop.  4.10. 

Proposition  4.10  Let  II  be  the  NetBill  protocol,  0  be  an  execution  in  £'(I1)C,  and  Pc  be  C’s 
protection  property  as  specified  in  Section  4-3.2.  Then 

<r  K  Pc- 

From  Prop.  4.7  and  4.10,  we  can  derive  the  following 
Corollary  4.11  NetBill  is  C -protective  under  deception  mode. 

Next  we  address  M-protection.  Like  in  the  analysis  of  (^-protection .  we  analyze  deceptive  and 
compliant  executions  in  turn. 

Proposition  4.12  Let  II  be  the  NetBill  protocol,  o  be  an  execution  in  E{ U)^,  T  be  the  trust 
assumptions  II  makes,  and  PM  =  -4  □(($ci  V  $C2)  -4  0(#a/i  V  $a/2))  be  M’s  protection 

property  as  specified  in  Section  4-3.2.  Then 

<7  |=*  T  implies  a  (=*  Pm- 


Proof: 

1.  Let  a  =  s0  ex  ...  be  a  trustworthy  execution  such  that  s0  |=  We  need  to  prove  that 
a  |=*  □  ($ci  V  4>C2  -4  0($a/i  V  $A/2))- 

2.  According  to  Lemma  4.13,  a  — >•  0$mi);  and  according  to  Lemma  4.14, 

er  (=*  D($c2  -4  04>m2). 


□ 

Bearing  in  mind  what  $a/2)  $ci  and  $C2  specify  (Section  4.3.2),  the  proof  of  Proposi¬ 

tion  4.12  shows  that  if  C  actually  received  the  goods,  then  M  has  proof  that  C  received  the  goods 
-  and  is  therefore  entitled  to  a  payment  (Lemma  4.13);  and  if  C  can  claim  the  goods  in  court,  then 
M  has  proof  that  N  committed  the  transaction  with  a  successful  result,  and  did  so  in  response  to 
a  valid  request  -  and  is  therefore  entitled  to  a  payment  (Lemma  4.14). 

Lemma  4.13  Let  II  be  the  NetBill  protocol,  a  be  an  execution  in  E(TV)m,  T  be  the  trust  assump¬ 
tions  II  makes,  and  Pm  =  — »  □((4,ci  V  $02)  -4  0($^i  V  (&M2))  be  M’s  protection  property  as 
specified  in  Section  4-3.2.  Then 

o'  (=*  T  implies  a  |=*  <&,■  ->•  n($ci  -4  0$mi)- 
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Lemma  4.14  Let  II  be  the  NetBill  protocol,  o  be  an  execution  in  E{U)^j,  T  be  the  trust  assump¬ 
tions  II  makes,  and  PM  =  □  (($ci  V  $02)  -t  0($mi  V  $M2))  be  M’s  protection  property  as 

specified  in  Section  J,.3.2.  Then 

o  (=*  T  implies  o  |=*  -4  n($C2  — >  0$AZ2)- 

Prop.  4.15  concerns  maximal  compliant  executions  and  can  be  proven  using  the  proof  for 
Prop.  4.12.  The  justification  is  analogous  to  that  for  Prop.  4.10. 

Proposition  4.15  Let  II  be  NetBill  protocol,  o  be  an  execution  in  E[Ii)c ,  and  Pm  be  M ’s  pro¬ 
tection  property  as  specified  in  Section  4-3.2.  Then 

<?  |=*  Pm- 

From  Prop.  4.12  and  4.15,  we  can  derive  the  following 
Corollary  4.16  NetBill  is  M -protective  under  deception  mode. 

Theorem  4.17  summarizes  the  results  in  this  subsection: 

Theorem  4.17  NetBill  is  all-protective  under  deception  mode. 

Proof:  From  Cor.  4.11  and  4.16. 


□ 

Discussion 

According  to  our  proofs,  C’s  interests  are  protected  under  deception  mode.  Intuitively,  M’s  mis¬ 
behavior  alone  cannot  compromise  C’s  interests.  This  can  be  explained  as  follows.  M  is  entitled 
to  a  payment  if  and  only  if 

1.  M  can  prove  that  C  received  the  goods,  or 

2.  M  can  prove  that  N  committed  the  transaction  with  a  successful  result,  and  did  so  in  response 
to  a  valid  request. 

We  examine  each  scenario  in  turn. 

1.  To  prove  that  C  received  the  goods,  M  needs  1)  a  C-signed  epo  as  a  proof  that  C  received 
an  encrypted  message;  2)  a  N- signed  transaction  slip  where  the  decryption  key  is  released; 
and  3)  a  proof  that  the  goods  is  retrievable  from  the  encrypted  message  and  the  decryption 
key.  C  must  have  received  an  encrypted  message,  otherwise  she  would  not  have  signed  the 
epo.  C  also  has  access  to  the  decryption  key  -  we  are  certain  of  this  access  because  the  key 
is  enclosed  in  the  transaction  slip  produced  by  N ,  and  this  slip  is  accessible  to  both  C  and 
M.  With  the  encrypted  message  and  the  decryption  key,  C  can  retrieve  the  goods. 
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2.  To  prove  that  N  committed  the  transaction  with  a  successful  result,  and  did  so  in  response 
to  a  valid  request,  M  needs  to  show  a  transaction  request  and  a  corresponding  slip  attesting 
to  such  a  result.  Both  these  messages  are  provided  by  N,  and  are  accessible  to  C.  If  the 
decryption  key  enclosed  in  the  slip  can  decrypt  the  encrypted  message  C  received,  then  C 
received  the  goods.  Otherwise,  either  M  or  N  misbehaved  and  an  invalid  key  was  released. 
C  does  not  receive  the  goods  during  the  protocol  execution  in  this  case,  and  needs  to  claim  it 
in  court.  To  do  so,  she  needs  to  show  that  decrypting  the  message  received  from  M  with  the 
key  released  by  N  does  not  yield  the  expected  goods.  This  can  be  easily  accomplished  by  C 
because  the  checksum  of  the  encrypted  message  -  which  attests  to  what  message  C  actually 
received  -  can  be  found  in  the  transaction  request,  and  the  key  released  by  N  can  be  found 
in  the  transaction  slip. 

Note  that  even  though  C  does  not  receive  the  goods  on-line  in  this  case,  her  interests  are  still 
protected.  NetBill’s  certified  delivery  mechanism  allows  C  to  prove  that  she  was  not  given  the 
goods  on-line,  and  claim  the  goods  -  or  a  refund  -  off-line.  Note  also  that  a  problem  with  the 
key  does  not  always  result  from  M’s  misbehavior;  N  can  be  the  one  to  blame.  For  example, 
M  may  enclose  the  right  key  in  the  transaction  request,  but  N  may  release  something  else 
other  than  this  key  in  the  slip. 

Our  proof  also  shows  that  protection  of  C s  interests  depends  on  iV’s  satisfying  the  trust  as¬ 
sumption  T/v5,  which  says  that  N  can  release  at  most  one  transaction  slip  per  transaction.  The 
discussion  following  the  proof  of  Lemma  4.8  in  Section  4.5  gives  the  intuition  behind  how  the 
violation  of  this  trust  assumption  can  compromise  C-protection. 

We  focus  on  M-protection  next.  According  to  our  proofs,  M’s  interests  are  protected  under 
deception  mode.  Intuitively  C’s  misbehavior  alone  cannot  compromise  M’s  interests.  In  what 
follows,  we  briefly  explain  why  this  is  the  case. 

There  are  two  ways  C  can  receive  the  goods: 

1.  she  can  receive  it  on-line,  or 

2.  she  can  claim  it  in  court. 

We  show  that  M  will  be  entitled  to  a  payment  in  either  case.  We  analyze  each  scenario  in  turn. 

1.  If  C  received  the  goods  on-line,  then  she  must  have  received  an  encrypted  message  and  must 
have  had  access  to  a  decryption  key  released  in  a  transaction  slip.  M  has  access  to  the  slip  C 
has  access  to,  and  would  not  have  enabled  its  generation  -  by  sending  a  transaction  request 
to  N  -  unless  he  had  received  a  C-signed  epo  attesting  that  C  had  received  an  encrypted 
message.  Using  the  slip  and  the  C-signed  epo,  M  can  prove  that  C  received  the  goods,  and 
therefore  be  entitled  to  a  payment. 

Note  that  in  this  case  C  could  not  have  misbehaved. 

2.  To  claim  the  goods  in  court,  C  needs,  among  other  messages,  an  iV-signed  transaction  slip  - 
attesting  to  afresh  and  successful  transaction  -  and  a  corresponding  valid  transaction  request. 
The  existence  of  these  two  messages,  in  their  turn,  entitles  M  to  a  payment. 

Note  that  C  could  not  have  misbehaved  in  this  case  either. 

Our  proof  also  shows  tha.t  M’s  interests  are  protected  only  if  Tn4  and  Tn4  are  assumed.  The 
discussion  following  the  proof  of  Lemma  4.13  in  Section  4.5  gives  an  intuition  of  how  the  violation 
of  these  trust  assumptions  can  compromise  M-protection. 
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4.4.3  Protection  under  Compliance  Mode 

In  this  subsection,  we  analyze  the  protocol  under  compliance  mode.  To  verify  whether  the  protocol 
is  all-protective  under  compliance  mode,  we  need  to  verify  whether  both  C's  and  M’s  interests 
are  protected  in  maximal  compliant  executions.  But  these  results  have  already  been  verified  in 
Subsection  4.4.2.  By  Prop  4.10  and  4.15, 

Theorem  4.18  NetBill  is  all-protective  under  compliance  mode. 

Discussion 

A  sale  transaction  in  NetBill  is  a  transaction  (in  the  database  sense  [47])  where  N  secures  the 
decryption  key  for  C  and  a  funds  transfer  for  M.  When  all  principals  behave  compliantly,  the 
key  secured  by  N  is  one  that  will  enable  C  to  retrieve  the  goods,  and  a  funds  transfer  to  which 
M  is  entitled  actually  occurs.  Given  that  the  key  retained  at  N  is  accessible  by  C,  a  transaction 
commit  effectively  implements  an  atomic  swap  of  goods  and  money  between  C  and  M.  This  atomic 
swapping  protects  both  C’s  and  M’s  interests. 

Note  that,  under  compliance  mode,  no  dispute  will  arise,  and  the  certified  delivery  mechanism 
is  not  really  needed. 

4.4.4  Protection  under  Abortion  Mode 

In  this  subsection,  we  analyze  the  protocol  under  abortion  mode.  As  in  the  two  previous  subsections, 
we  need  to  verify  whether  the  protocol  is  both  C'-protective  and  M-protective.  We  start  with  C- 
protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  to  verify  whether  II  protects  C’s  interests 
under  abortion  mode,  we  need  to  examine  all  executions  in  E(Ii)c  and  trustworthy  executions  in 
E{J\)q.  Here  we  focus  on  abortive  executions  only,  since  we  have  analyzed  compliant  executions 
(Prop.  4.10)  in  Section  4.4.2. 

Proposition  4.19  Let  II  be  the  NetBill  protocol,  a  be  an  execution  in  E{L[)q,  T  be  the  trust 
assumptions  n  makes,  and  Pc  be  X ’s  protection  property  as  specified  in  Section  4-3.2.  Then 

o\=*T  implies  o  [=*  Pc- 

Prop.  4.19  can  be  proven  using  the  proof  for  Prop.  4.7.  That  proof  is  applicable  here  because 
it  relies  only  on  the  fact  that  executions  it  considers  are  trustworthy  and  have  compliant  local 
executions  of  C,  both  of  which  are  satisfied  by  executions  we  consider  under  Prop.  4.19.  A  critical 
condition  satisfied  by  the  proof  is  that  it  does  not  depend  on  M  or  N  taking  further  steps,  a 
requirement  that  could  be  violated  by  abortive  executions. 

Jointly,  Prop.  4.10  (Section  4.4.2)  and  4.19  address  C-protection  under  abortion  mode,  and 
derive  the  following 

Corollary  4.20  NetBill  is  C-protective  under  abortion  mode. 

Prop.  4.21  addresses  protection  of  M’s  interests  in  abortive  executions  and  can  be  proven 
using  the  proof  for  Prop.  4.12  (Subsection  4.4.2).  The  reason  why  that  proof  is  applicable  here  is 
analogous  to  the  one  given  for  Prop.  4.19. 
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Proposition  4.21  Let  II  be  the  NetBill  protocol,  a  be  an  execution  in  E(  L\)m,  T  be  the  trust 
assumptions  II  makes,  and  Pm  be  M ’s  protection  property  as  specified  in  Section  4-3.2.  Then 

o  (=*  T  implies  o  |=*  Pm- 

Jointly,  Prop.  4.15  (Section  4.4.2)  and  4.21  address  M-protection  under  abortion  mode.  They 
derive  the  following 

Corollary  4.22  NetBill  is  M -protective  under  abortion  mode. 

Theorem  4.23  summarizes  the  results  in  this  subsection. 

Theorem  4.23  NetBill  is  all-protective  under  abortion  mode. 

Proof:  From  Cor.  4.20  and  4.22. 


□ 


Discussion 

Our  proofs  show  that  NetBill  is  all-protective  even  if  its  principals  terminate  their  local  executions 
prematurely.  This  is  not  surprising  because  the  exchange  of  the  decryption  key  and  payment 
happens  atomically  in  NetBill.  If  a  party  stops  prematurely  its  own  local  execution  and  prevents 
N  from  committing  the  transaction,  then  neither  the  decryption  key  is  released  nor  are  funds 
transferred . 

Since  the  only  possible  deviations  here  are  premature  terminations,  the  decryption  key  released 
by  N  is  the  one  that  will  decrypt  the  encrypted  message  and  produce  the  goods.  Here  too,  reliability 
of  communication  channels  is  irrelevant.  If  C  does  not  receive  the  decryption  key  at  the  end  of  a 
protocol  execution,  she  can  get  it  from  N  off-line. 

M  is  entitled  to  the  funds  credited  into  his  account  because  he  can  prove  that  C  received  the 
goods. 

Under  abortion  mode,  no  dispute  will  arise,  and  the  certified  delivery  mechanism  is  not  really 
needed. 


4.5  Formal  Analysis  of  the  Protocol 

4.5.1  Preliminaries 

Lemma  4.4  Let  n  be  the  NetBill  protocol  and  7jv  =  { Tjy3 .  7\, ,  Tv. }  be  the  trust  assumptions  we 
make  of  Z  (as  specified  in  Section  4-3.1).  Then 

Va  e  E( n)c,  a  K  Tn3. 


Proof: 
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1.  Let  Si  be  a  state  in  a  such  that  s,-  |=  commit(mi,  -)  £  HN,  for  some  signed  slip  mi.  Then 
3sj,j  <  i,  such  that 

Sj  |=  last(HN)  -  commit(mi,  — )  and  Sj_i  j=  commit(rai,  — )  ^  HN. 

Examining  iV’s  local  protocol,  we  can  conclude  that,  either  R  y.2  or  Ry3  was  applied  at  Sj—i • 

2.  Independently  of  which  rule  was  applied,  m\  =  b  seal(6,  k”1),  for  a  slip  b. 

3.  Given  that  key  Pair  (k”1,  Kn)  holds,  we  can  conclude  that  vseal(6,  seal(6,  k"1),  Kn)  =  True. 

□ 

Lemma  4.5  Let  II  be  the  NetBill  protocol  and  Tn  =  {Tn3,  TNi,  TNs}  be  the  trust  assumptions  we 
make  of  Z  (as  specified  in  Section  4-3.1).  Then 

Mo  €  E{U)C,  (T  |=*  TN4. 

Proof:  Commit  events  are  prescribed  by  rules  Ry?  and  Ry?  only,  both  of  which  prescribe  using  the 
customer  id,  the  merchant  id,  and  the  transaction  id  from  the  transaction  request  in  the  transaction 
slip. 

□ 

Lemma  4.6  Let  II  be  the  NetBill  protocol  and  Tn  =  {Tn3,Tn4,TNs}  be  the  trust  assumptions  we 
make  of  Z  (as  specified  in  Section  4-3.1).  Then 

Me  £  E{Y[)C ,  o  (=*  Tns- 

Proof:  The  only  rule  that  prescribes  a  send(M,  x)  event  is  Rn4,  which  requires  x  to  result  from  a 
commit  event. 

□ 


4.5.2  Protection  Under  Deception  Mode 

Lemma  4.8  Let  II  be  NetBill  protocol,  a  be  an  execution  in  E(U)%,  T  be  the  trust  assumptions  II 
makes,  and  Pc  =  -4  □(($ji/i  V  $ m2 )  0($Ci  V  $02))  be  C’s  protection  property  as  specified 

in  Section  4-3.2.  Then 

a  |=*  T  implies  o  |=*  D($mi  — t 

Proof:  Let  o  =  s0  ei  «i  •  •  •  be  such  that  a  \=*  T  and  a  |=*  And  let  Si  be  a  state  in  o  such 
that  S{  |=  $mi-  The  following  shows  that  s,  |=  $ci- 

1.  If  Si  |=  $mu  then  there  exists  a  signed  epo  m\  :  tsepo  such  that 

Si  |=  receive  (C,  mf)  £  HM, 

which  implies  that 
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Si  |=  send(M,  m4)  £  Hc. 

2.  Given  that  “send(M,  mj)”  could  have  resulted  only  from  applying  Rc3,  we  know  that  there 
is  a  message  ra2  m3  m4  :  t  x  i-C&s  x  tJid  such  that 

Si  (=  receive(M,  m2  m3  m4)  6  Hc. 

3.  Next,  let  m 5  :  tsslip  be  the  signed  slip  such  that 

Si  (=  commit(m5,  -)  £  HN. 

(Lemma.  4.24  allows  us  to  ignore  the  occurrence  of  “receive(iV,  m5)”  at  M,  which  may  or  may 
not  have  taken  place.) 

We  now  need  to  prove  that  m5.msg.cid  =  (f>c. id  (step  4),  m5. msg.tid  =  m4  (step  5)  and 
dec(m2,  m5.msg.key)  =  7  (step  6). 

4.  From  <I>Afi)  we  know  that  m5.msg.cid  =  mi.msg.cid.  Given  that 

(a)  “send*-7 (M,  mi)”  could  have  resulted  only  from  applying  Rc3,  and 

(b)  mi.msg.cid  =  lc, 

we  can  conclude  that  m5.msg.cid  =  mi.msg.cid  =  tc.  But  ic  =  <^>c.id,  according  to  the  initial 
condition  X.  Thus,  m5.msg.cid  =  <j)c.\d. 

5.  Again,  from  4>mi,  we  know  that  m5. msg.tid  =  m^ msg.tid.  And  according  to  Lemma  4.26, 
mi.msg.tid  =  m4.  Thus,  by  transitivity,  ms. msg.tid  =  m4. 

6.  (a)  From  st-  (=  send (M,  mi)  £  Hc  and  Lemma  4.25,  we  know  that  cc(m2)  =  m3. 

(b)  According  to  Lemma  4.26,  m3  =  mi.msg.cks.  And  using  the  result  from  step  (a)  and 
transitivity,  we  know  that  cc(m2)  =  mi.msg.cks. 

(c)  Now,  according  to  $mi,  cc(enc(7,  m5.msg.key))  =  mi.msg.cks.  By  transitivity  (using 
the  result  from  step  (b)),  cc(m2)  =  cc(enc(7,  m5.msg.key));  which  allows  us  to  conclude 
that  m2  =  enc(7,  m5.msg.key),  and  consequently  dec(m2,  m5.msg.key)  =  7. 


□ 

To  prove  that  C  received  the  goods,  M  needs,  among  other  things,  to  have  received  a  fresh 
C-signed  epo  attesting  that  C  has  received  an  encrypted  message  with  the  enclosed  checksum.  Our 
proof  of  Lemma.  4.8  shows  that  C  signs  this  epo  only  if  she  actually  receives  the  encrypted  message. 
As  for  the  decryption  key,  our  proof  shows  that  C  does  not  depend  on  M’s  forwarding  back  the 
transaction  slip  to  obtain  it;  she  can  retrieve  it  directly  from  N .  Given  that  N  controls  access  to  its 
data  through  authentication,  C  can  retrieve  the  transaction  slip  from  N  as  long  as  she  can  prove 
that  she  is  in  fact  C. 

Our  proof  also  shows  that  the  trust  assumption  T/vs  is  critically  important  here.  In  fact,  if 
does  not  hold,  then  it  is  possible  for  M  to  prove  that  C  received  the  goods  without  C  actually 
receiving  it.  We  show  how  this  is  possible  below. 

If  Tns  does  not  hold,  then  it  is  possible  for  N  to  send  M  a  slip  m  different  from  the  one,  m', 
generated  when  the  transaction  committed.  Let  us  now  assume  that  m  and  m1  only  differ  in  the 
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value  of  the  decryption  key  they  enclose:  let  the  key  enclosed  in  m  be  the  right  key,  and  the  one 
enclosed  in  m!  be  a  wrong  key.  Let  us  further  assume  that  C  does  not  receive  m  from  M  because 
of  a  communication  link  failure.  Then,  at  the  end  of  the  execution,  will  hold  if  M  has  also 
received  the  signed  epo  from  C.  Since  C  does  not  receive  the  transaction  slip  from  M,  she  will  get 
it  from  TV,  who  will  provide  the  copy  m' .  But  according  to  our  assumptions  m'.msg.key  cannot 
decrypt  the  encrypted  message  C  received.  Effectively,  C  does  not  receive  the  goods  at  the  end  of 
the  transaction,  and  3>ci  does  not  hold. 

Note  that,  in  this  case,  C  will  not  even  be  able  to  claim  the  goods  in  court,  unless  TV  has  kept 
a  copy  of  the  transaction  request  and  makes  it  available  to  the  arbitrator. 

Lemma  4.9  Let  II  be  NetBill  protocol,  o  be  an  execution  in  E(U)^,  T  be  the  trust  assumptions  II 
makes,  and  Pc  =  ->  □(($mi  V  $m2)  <>{$ci  V  $02))  be  C’s  protection  property  as  specified 

in  Section  4-3.2.  Then 


O  |=*  T  — >  O  |=*  -4-  □($M2  — >■  0($ci  V  $C2))- 

Proof:  Let  o  —  s0  e\  Si  ...  be  such  that  o  \=*  T  and  o  1=*  And  let  S{  be  a  state  in  o  such 
that  Si  |=  $M2-  The  following  shows  that  Si  \=  $ci  V  $C2- 

1.  If  Si  |=  <&M2,  then  there  exists  a  signed  slip  mi  and  signed  transaction  request  m8  such  that 

Si  |=  commit(mi,  m8)  €  HN. 

Note  that  Lemma  4.24  allows  us  to  ignore  the  occurrence  of  “receive(TV,  mi)”  at  M,  which 
may  or  may  not  have  occurred. 

2.  To  be  useful  to  C ,  mi  must  be  accessible  by  C  (both  $ai  and  $C2  specify  this  condition). 
That  is, 

Si  j=  mi.msg.cid  =  <£c.id. 

But  we  know,  from  $M2  that 

Si  |=  mi.msg.cid  =  m8.msg.sepo.msg.cid  A  m8.msg.sepo.msg.cid  =  <j)c. id, 
which  implies  that 

Si  \=  mi.msg.cid  =  </>c.id. 

3.  Also,  according  to  $M2,  mi.msg.tid  ^  0.  Applying  contrapositive  to  the  implication  regarding 
transaction  ids  in  we  conclude  that  mi.msg.tid  is  not  a  submessage  of  messages  retrievable 
from  s0(MSN);  hence,  it  must  have  received  it  from  M.  That  is,  there  must  be  a  transaction 
request  m2  :  t.str  such  that 

Si  \=  receive(M, m2)  €  HN  A  mi.msg.tid  C  m2. 

4.  Examining  the  structure  of  m2,  we  conclude  that 

mi.msg.tid  =  m2.msg.sep0.msg.tid. 

5.  Still  according  to  3>m2>  m8.msg.sepo.msg.tid  =  mi.msg.tid. 
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6.  Also  according  to  4>M2 


Si  |=  vseal(77r8.msg.sepo.msg,  m8. msg.sepo.sig,  <^c.key),  (4.1) 

which  implies  that  there  exists  a  private  key  k  :  t.prik  such  that 

Si  |=  m8. msg.sepo.sig  =  seal(m8.msg.sepo.msg,  k)  A  keyPair(fc,  <^>c.key). 

7.  Now,  according  to  the  initial  condition  X,  k"1  is  such  that  keyPair^"1,  </>c.key);  and  kJ1  is 
kept  private  to  C  throughout  the  execution.  Thus,  N  could  not  have  produced  m8. msg.sepo.sig 
locally,  and  must  have  received  it  as  a  submessage  of  m2  from  M. 

8.  Applying  the  reasoning  steps  we  just  used  to  conclude  that  m8. msg.sepo.sig  could  not  have 
been  built  locally  by  N,  we  also  conclude  that  m8. msg.sepo.sig  could  not  have  been  built 
locally  by  M ,  and  therefore  there  must  exist  a  signed  epo  to4  :  tsepo  such  that 

(  Si  \=  receive  (C,  m4)  €  HMA 

1  m8. msg.sepo.sig  C  m4.  '  '  ' 

Now,  given  that  messages  must  be  sent  before  they  are  received,  we  have 

Si  |=  send  (M,  ra4)  €  Hc.  (4.3) 

By  Lemma  4.25,  we  conclude  that  there  exists  m5  m?  :  t  x  t-cks  X  tJid  such  that 

Si  |=  receive(M,  m5  m6  to7)  6  Hc,  (4.4) 

(which  is  one  of  the  conjuncts  in  both  <f>ci  and  $02)- 

9.  Also,  unless  m\  has  the  transaction  id  C  is  focused  on  in  this  transaction  (m7),  it  may  be 
ignored  by  C  as  useless  data.  This  justifies  why  we  require  that 

mi.msg.tid  =  m7, 

as  is  specified  in  both  4>ci  and  $02-  We  prove  this  last  equality  below: 

(a)  From  expression  4.2  (step  8)  and  the  structure  of  m4,  we  know  that 

m8. msg.sepo.sig  =  m4.sig. 

(b)  Using  straightforward  steps  omitted  here,  we  can  prove  that 

Si  |=  vseal(m4.msg, m4.sig, d>c.key), 

which,  in  conjunction  with  expression  4.1  (step  6),  allows  us  to  prove  that 

TOs.msg.sepo  =  m4.  (4.5) 

(c)  Applying  Lemma  4.26  to  expressions  4.3  and  4.4  (step  8),  we  know  that 

m4.msg.tid  =  m7.  (4.6) 
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(d)  From  $M2,  we  know  that 


mj.msg.tid  =  m8.msg.sepo.msg.tid.  (4.7) 

Now,  applying  transitivity  to  expressions  4.7,  4.5,  and  4.6,  we  conclude  that 
mj.msg.tid  =  m-j. 

10.  If  dec(ro5,  mj.msg.key)  =  7,  then  |=  $ci-  Otherwise,  we  need  to  prove  that 

cc(m5)  =  ms-msg.sepo.msg.cks, 
which  is  what  we  do  in  the  remainder  of  this  proof. 

11.  Proving  that  cc(m5)  =  mg.msg.sepo.msg.cks: 

(a)  According  to  Lemma  4.25,  cc(m5)  =  m6. 

(b)  According  to  Lemma  4.26,  m6  =  m4.msg.cks.  And,  by  transitivity,  cc(m5)  =  m4. msg.cks. 

(c)  We  know,  from  step  8,  that 

ms.msg.sepo.sig  C  m4. 

Examining  the  structure  of  m4,  we  can  conclude  that  ms-msg.sepo.sig  =  m4.sig. 

(d)  And,  by  straightforward  steps  omitted  here,  we  can  prove  that 

vseal(m4.msg,  m4.sig,  <j>c. key). 

(e)  But  we  also  know  (from  step  6)  that 

vseal(m8.msg.sepo.msg,  mg.msg.sepo.sig,  <£c.key). 

(f)  Using  (c)-(e)  ,  we  can  then  conclude  that 

m4.msg  =  m8.msg.sepo.msg. 

(g)  Finally,  combining  (b)  and  (f),  we  obtain 

cc(ms)  =  ms-msg.sepo. msg.cks. 

12.  All  the  other  conjuncts  in  $02  can  be  obtained  as  they  are  from  $M2- 


□ 

Recall  from  Subsection  4.3.2  that  M  needs  two  messages  to  prove  that  N  committed  a  new 
transaction  with  a  successful  result,  and  did  so  in  response  to  a  valid  request:  a  fresh  Assigned 
slip  and  a  corresponding  transaction  request.  In  her  turn,  C  needs  an  encrypted  message  and  a 
decryption  key  enclosed  in  a  transaction  slip  to  obtain  the  goods.  Our  proof  of  Lemma  4.9  shows 
that:  1)  both  the  slip  and  the  transaction  request  that  service  M  also  service  C;  and  2)  C  must 
have  received  an  encrypted  message  if  a  fresh  slip  was  generated  by  N.  That  is,  if  M  can  claim 
his  entitlement  to  a  payment  by  showing  that  a  transaction  -  that  C  and  himself  agreed  on  -  was 
carried  through,  then  C  will  obtain  the  goods. 

We  focus  in  turn  on  smaller  steps  below. 

The  slip  and  the  transaction  request  that  service  M  also  service  C  because  N  makes  them 
available  to  both  parties  involved  in  the  transaction. 
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C  must  have  received  an  encrypted  message  because  1)  N  only  generates  a  signed  slip  attesting 
to  a  successful  result  if  N  receives  a  fresh  transaction  request  correctly  signed  by  C  and  M;  2)  fresh 
transaction  requests  could  not  be  generated  unless  C  signs  an  epo  in  the  current  execution;  and  3) 
C  only  signs  an  epo  if  she  receives  an  incorrupt  encrypted  message.  Note  that  the  assumption  ($,•) 
that  there  is  no  pending  transactions  at  the  beginning  of  the  protocol  execution  is  important  here. 

With  the  encrypted  message  and  the  decryption  key  enclosed  in  the  transaction  slip,  C  may 
or  may  not  be  able  to  retrieve  the  goods.  If  the  encrypted  message  can  be  decrypted  by  the 
decryption  key,  then  C  obtains  the  goods  at  the  end  of  the  protocol  execution,  and  no  dispute 
is  needed.  Otherwise,  C  will  need  to  claim  the  goods  in  court.  C  can  do  so  by  showing  to  the 
arbitrator  that  the  encrypted  message  she  received  is  consistent  with  the  checksum  sanctioned  by 
both  C  and  M,  but  cannot  be  decrypted  using  the  decryption  key  provided  by  N.  Our  proof  shows 
that  the  checksum  enclosed  in  the  transaction  request  is  in  fact  the  checksum  against  which  C 
checked  the  integrity  of  the  encrypted  message.  (The  checksum  is  signed  by  C,  and  because  the 
signed  message  includes  a  fresh  transaction  id,  the  signature  cannot  be  a  replay.) 

Note  that  even  though  we  use  Lemma  4.24,  and  ultimately  T/v5,  in  this  proof,  they  are  not 
strictly  necessary  here.  That  is,  Lemma  4.9  can  be  proven  even  if  T/vs  does  not  hold  in  a.  Its 
assumption,  however,  makes  the  proof  simpler.  Intuitively,  Tn5  is  not  needed  here  because  we  are 
under  scenarios  where  transaction  requests  are  kept  by  N  and  made  available  to  the  arbitrator. 
The  availability  of  transaction  requests  makes  the  role  of  transaction  slips,  and  their  uniqueness, 
less  critical.  Effectively,  no  matter  what  key  N  encloses  in  the  slip,  we  can  always  resort  to  the 
transaction  request,  and  either  get  the  key  directly  from  there,  if  the  key  enclosed  in  the  request  is 
the  right  decryption  key,  or  demand  it  from  M  otherwise. 

The  following  three  lemmas  appear  in  our  proof  of  Lemma  4.9.  Lemma  4.24  says  that  the 
slip  M  receives  from  N  is  the  one  generated  with  the  transaction  commit  and  retained  at  N .  Its 
proof  consists  of  straightforward  baekchaining  steps  and  relies  on  the  fact  that  1)  N  sends  the  slip 
only  after  it  commits  the  transaction,  and  2)  N  is  trusted  to  send  M  the  slip  generated  with  the 
transaction  commit  (T/vs). 

Lemma  4.24  Let  If  be  NetBill  protocol,  a  be  an  execution  in  E(J\)q,  T  be  the  trust  assumptions 
14  makes.  Then 

a  \=*  T  implies  a  (=*  Mx  :  tsslip,  □(receive(7V,  x)  £  HM  — >•  commit(a:,  -)  £  HN). 

Proof:  Let  a  be  a  trustworthy  execution,  s8-  be  a  state  in  <7,  and  Wj  :  tsslip  be  a  signed  slip  such 
that 


Si  |=  recei ve(N,  mi)  £  HM. 

Given  that  messages  must  be  sent  before  they  are  received,  we  know  that 
Si  )=  send(M,  mi)  £  HN. 

By  T;v5,  we  can  conclude  that  s,  |=  commit  (raj,  — )  £  HN. 


□ 

Lemma  4.25  says  that  if  C  sends  a  signed  epo  to  M ,  then  C  received  an  encrypted  message, 
and  the  message  is  consistent  with  the  accompanying  checksum.  Our  proof  relies  on  the  fact  that 
C  behaves  compliantly. 
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Lemma  4.25  Let  n  be  NetBill  protocol  and  a  be  an  execution  in  E{J[)q.  Then 

a  |=*  □(Bzi  :  t.sepo  |  send(M,  zi)  £  Hc  -> 

3x2  £3  x4  :  t  X  t-cks  X  tJid  |  (receive(M,  z2  x3  x4)  £  Hc  A  ec(z2 )  =  Z3)). 

Proof:  Let  s,  be  a  state  in  a  and  m\:  tsepo  be  a  message  such  that 
Si  |=  send(M,  mi)  £  Hc. 

“send(M,  mi)”  could  have  resulted  only  from  an  application  of  Rc3 •  Thus,  3 sj,j  <  i,  such  that 
Sj  |=  last(Hc)  =  send(M,  mj) 

and 

Sj- 1  |=  send(M,  mi)  ^  HCA 

3x2  x3  x4  :  t  X  t.cks  X  tJtid  |  last(Hc)  =  receive(M,  x2  z3  x4)  A  cc(z2)  =  x3. 

□ 

Lemma  4.26  says  that  the  checksum  and  the  transaction  id  enclosed  in  the  signed  epo  C  sends 
to  M  are  the  ones  C  received  from  M.  Its  proof  also  relies  on  the  fact  that  C  behaves  compliantly. 

Lemma  4.26  Let  n  be  NetBill  protocol  and  a  be  an  execution  in  E(U.)q.  Then 

a  \=*  Vzi  x2  z3  :  t  X  t.cks  x  t.tid ,  x4  :  tsepo , 

□  (receive(M,  x4  x2  x3)  £  Hc  Asend(M,  x4)  £  Hc  — > 
z2  =  Z4.msg.cks  A  £3  =  Z4.msg.tid). 

Proof: 

1.  Let  Si  be  a  state  in  <7  and  m\,...,m4  be  messages  such  that 

Sj  |=  receive(M,  mi  m2  m3)  £  Hc  A  send(M,  7714)  £  Hc. 

2.  Examining  C’s  local  protocol,  we  conclude  that  “send(M,  m.4)”  could  have  resulted  only  from 
an  application  of  Rc3.  This  implies  that,  if  Sj,j  <  i ,  is  the  state  at  which  Rcs  is  applied,  i.e., 

Sj  f=  send  (M,  m4)  ^  Hc  A  Sj+ 1  |=  send(M,  m4)  £  Hc, 


then 

Sj  [=  receive(mi,  m2,  m3)  £  Hc,  and 
m4.msg.cks  =  m2  A  m4.msg.tid  =  m3. 

□ 

Lemma  4.13  Let  n  be  the  NetBill  protocol,  a  be  an  execution  in  T  be  the  trust  assump¬ 

tions  U  makes,  and  PM  =  $j  -4  □  (($<?!  V  $02)  -4  0($mi  V  $^2))  be  M’s  protection  property  as 
specified  in  Section  4-3.2.  Then 

a  |=*  T  implies  a  |=*  $j  -4  □  (#ci  -4  0$mi)- 
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Proof:  Let  a  —  so  e\  sy  ...  be  such  that  <7  |=*  T  and  a  |=*  and  let  s,-  be  a  state  in  a  such  that 
Si  \=  $ci-  The  following  shows  that  S{  (=  ^mi- 

1.  If  Si  \=  $ci,  then  there  exists  messages  mj  m2  m3  :  t  X  t..cks  X  tJid  and  m4  :  tsslip  such 
that 

Si  |=  receive(M,  mi  m2  m3)  G  HCA 
commit(m4,— )  G  HNA 
dec(mi,  m4.msg.key)  =  7. 

For  simplicity  of  the  proof,  we  have  applied  Lemma  4.27  here. 

To  prove  that  Si  \=  $mi,  we  first  need  to  show  that  M  received  a  signed  epo  from  C  (steps  2,  3, 
and  4): 

2.  Given  that 

Si  \=  commit(m4,  — )  G  HM  (from  step  1) 

we  can  conclude  that  either  Rn2  or  Rnz  has  been  applied.  In  either  case,  3j,  j  <  i.  and  a 
message  m.5 :  t.str  such  that 

Sj  |=  last(HM)  =  receive(M,  m3). 

3.  Since  messages  must  be  sent  before  they  are  received,  we  have 

Sj  (=  send  (N,  7715)  G  HM 

4.  “send (N,  07,5)”  could  have  only  resulted  from  an  application  of  Rm6,  which  implies  that 
3k,  k  <  j,  and  a  signed  epo  me:  t.sepo,  such  that 

Sk  |=  last(HM)  =  send(iV,  m$),  and 
Sfc_!  |=  last(HM)  =  receive (C,  me). 

Next  we  show  that  m6  is  C-signed  (steps  5,  6,  and  7): 

5.  Going  back  to  step  2,  an  application  of  Rn2  or  Rn3  actually  allows  us  to  draw  more  con¬ 
clusions.  For  instance,  the  signed  epo  included  in  the  transaction  request  must  be  signed  by 
C: 


s3  |=  m5.msg.sepo.msg.cid  =  <^>c.id  A  vseal(m5.msg.sepo.msg,  m5.msg.sepo.sig,  ^>c.key) 

6.  In  step  4,  an  application  of  Rms  also  leads  to  more  conclusions.  For  example,  the  signed  epo 
enclosed  in  the  transaction  request  m5  is  the  one  received  from  C: 

m5.msg.sep0  =  me. 

7.  From  steps  5  and  6,  we  can  conclude  that 

vseal(m6.msg,  m6.sig,  </>c.key) 
holds,  that  is,  me  is  C-signed. 
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We  also  need  to  prove  that  s  transaction  id  is  fresh,  i.e.,  mg.msg.tid  d  ©  (steps  8  and  9): 

8.  Going  back  again  to  step  4,  we  list  other  conditions  that  s^-i  satisfies.  For  example,  there 
are  messages  m\  :  t,  m2  :  t.cks  and  m3  :  tJid.  such  that 

Sk- 1  1=  send (C,  m[  m2  m3 )  e  HM  A  m2  =  m6.msg.cks  A  m'3  =  m6.msg.tid. 

9.  “send(C,  m'j  m2  m3)”  could  have  resulted  only  from  an  application  of  Rm4,  which  implies 
that  was  generated  by  a  “new(0,m3)”  event.  Thus,  m3  £  ©. 

Given  that  m3  =  m6.msg.tid  (step  8),  we  can  conclude  that  m6.msg.tid  ^  0. 

Next,  we  show  that  the  signed  slip  generated  during  the  transaction  processing  is  signed  by  N  (step 
x)  and  has  the  required  values  for  its  customer  id,  merchant  id  and  transaction  id  (steps  11,  12, 
and  13),  i.e., 

m4.msg.mid  =  (f>m .id  A  m4.msg.cid  =  m6.msg.cid  A  m4.msg.tid  =  mg.msg.tid 

10.  To  show  that  the  slip  is  iV-signed  is  to  show  that 

vseal(m4.msg,  m4.sig,  Kn). 

But  from  step  1,  we  know  that  s;  |=  commit(m4,  -)  6  HM.  And  according  to  Tn3, 
vseal(m4.msg,  m4.sig,  Kn ). 

11.  Going  back  to  step  2,  an  application  of  R^2  or  Rn3  allows  us  to  conclude  that  the  transaction 
request  m5  is  signed  by  M: 

Sj  |=  m5.msg.mid  =  ^>TO.id  A  vseal(m5.msg,  ms.sig,  ^>m.key). 

And  T/v4  says  that  the  transaction  slip  generated  during  the  transaction  processing  uses  the 
value  of  mid  from  m§  in  its  mid  field.  That  is: 

m4.msg.mid  =  m5.msg.mid. 

By  transitivity,  we  conclude  that  m4.msg.mid  =  (f>m- id. 

12.  From  $ci,  we  know  that  m4.msg.cid  =  <f>c. id;  from  step  5,  we  know  that  m5.msg.sepo.msg.cid  =  <^c.id; 
and  from  step  6  we  know  that  m5.msg.sep0  =  me-  By  transitivity,  m4. msg.cid  =  m6. msg.cid. 

13.  From  4>ci)  we  know  that  m4.msg.tid  =  m3.  From  step  8,  m3  =  m6.msg.tid.  Given  that 
“send(G,  m'j  m2  m^)”  takes  place  only  once  in  M’s  execution,  we  can  conclude  that  mi  = 
m'j,mi  -  m[,mi  -  m'v  By  transitivity,  m4.msg.tid  =  m6.msg.tid. 

Finally  (step  13),  we  prove  that  cc(enc(7,  m4.msg.key))  =  m6.msg.cks. 

13.  From  $ci,  we  know  that  dec(mi,m4.msg. key)  =  7,  which  implies  that  mj  =  enc(7,  m4.msg.key). 
Applying  cryptographic  checksum  on  both  sides  of  the  equality,  we  get 

cc(mi)  =  cc(enc(7,  m4.msg.key)). 

Going  back  to  step  9,  the  fact  that  “send(C,  m\  m2  m3)”  could  have  resulted  only  from  an 
application  of  Rm4  also  implies  that 
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cc(mx)  =  m2. 

Given  that  mx  =  m[,  we  can  conclude  by  transitivity  that  m'2  =  cc(enc(7,  m4.msg.key)).  But 
from  step  8,  we  know  that  m2  =  m6.msg.cks,  which  allows  us  to  finally  conclude  that 

cc(enc(7,  m4.n1sg.key))  =  m6.msg.cks. 


□ 

Our  proof  of  Lemma  4.13  shows  that  if  C  can  obtain  the  goods  from  the  encrypted  message  she 
received  from  M  and  the  key  released  in  the  transaction  slip  she  has  access  to,  then  M  can  prove 
that  C  received  an  encrypted  message  and  a  key  that  would  allow  her  to  retrieve  the  goods. 

We  focus  in  turn  on  smaller  steps  below. 

If  C  has  access  to  a  transaction  slip,  then  TV  must  have  committed  a  transaction,  which  must 
have  been  requested  by  M.  M  must  have  received  a  signed  epo  from  C,  otherwise  he  would  not 
have  submitted  the  transaction  request. 

This  epo  must  be  fresh  and  must  have  been  signed  by  C.  It  must  be  fresh  because  M  would 
not  have  proceeded  with  the  protocol  otherwise.  And  it  must  have  been  signed  by  C ,  because  TV 
would  not  have  committed  the  transaction  otherwise.  With  this  fresh,  C-signed  epo,  M  can  prove 
that  C  received  an  encrypted  message  during  the  protocol  execution. 

Next,  we  show  that  the  slip  from  which  C  extracts  the  key  is  accessible  to  M.  This  is  so  because 
the  transaction  request  submitted  by  M  identifies  him  as  the  merchant  (remember  that  M  behaves 
compliantly  here),  and  TV  faithfully  transcribes  this  information  to  the  only  slip  it  generates  per 
transaction.  Note  that,  to  be  useful  in  court,  this  slip  needs  to  be  TV-signed. 

Finally,  through  the  value  of  the  checksum  enclosed  in  the  C-signed  epo,  M  can  show  that  C 
can  retrieve  the  goods  from  the  encrypted  message  C  received  and  the  key  released  in  the  slip.  He 
does  so  by  showing  that  the  encrypted  message  and  the  result  of  encrypting  the  goods  with  the 
key  have  the  same  checksum. 

Our  proof  relies  on  three  trust  assumptions:  TNi,  T/v4  and  T/vs.  T/v4  is  critical  because  it  makes 
Aps  intermediation  actions  non-repudiable.  In  the  context  of  this  proof,  non-repudiation  allows 
M  to  use  the  slip  TV  released  to  prove  that  the  decryption  key  was  in  fact  released  by  TV  and  is 
accessible  to  C.  If  T/v4  did  not  hold,  then  TV  might  release  a  slip  that  is  not  signed,  which  would 
not  help  M  in  court. 

Tn4  is  critical  because  it  guarantees  that  the  values  of  customer  id  and  merchant  id  enclosed 
in  the  transaction  slip  are  exactly  those  from  the  transaction  request.  These  values  are  important 
here  because  they  determine  whether  the  slip  C  has  access  to  is  also  accessible  to  M.  Remember 
that  M  needs  a  TV-signed  slip  and  a  corresponding  C-signed  epo  to  make  his  case.  If  T/v4  does  not 
hold,  then  TV  could  generate  a  slip  that  is  accessible  to  C,  but  not  to  M.  If  this  slip  also  encloses 
the  decryption  key,  C  would  effectively  get  the  goods,  without  M’s  being  able  to  prove  it.  At  a 
higher  level  of  abstraction,  this  depicts  a  scenario  where  TV  cheats  by  giving  the  decryption  key  to 
C  behind  M’s  back. 

Tn5  is  not  critical  for  Lemma  4.13  to  hold.  It  only  simplifies  the  proof.  If  T/v5  does  not  hold, 
then  TV  might  send  M  a  copy  of  the  slip  that  is  different  from  the  one  retained  at  TV.  In  the  worst 
case,  the  copy  sent  to  M  will  not  enclose  the  key,  while  the  one  retained  at  TV  will.  Under  this 
scenario,  C  can  get  the  goods,  and  M  may  not  even  know  about  it.  But  M  can  always  uncover 
these  cases  by  checking  whether  the  slip  he  received  is  a  copy  of  the  one  retained  at  TV. 
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Lemma  4.27  was  used  in  our  proof  of  Lemma  4.13.  It  says  that  in  trustworthy  executions  where 
M  behaves  compliantly,  the  slip  received  by  C  is  the  one  retained  at  N.  Its  proof  relies  on  1)  the 
fact  that  M  behaves  compliantly  -  and  thus  forwards  the  message  he  receives  from  N  to  C,  and 
2)  the  assumption  (TN&)  that  N  is  trusted  to  send  M  only  the  slip  produced  with  the  transaction 
commit  and  retained  at  N. 

Lemma  4.27  Let  II  be  the  NetBill  protocol,  o  be  an  execution  in  E(U)fy,  and  T  be  the  trust 
assumptions  IT  makes.  Then 

a  \=*  T  implies  a  \=*  'ix  :  tsslip,  D[receive(M,  x)  G  Hc  — >■  commit(a:,  -)  G  Hw). 


Proof: 

1.  Let  o  be  a  trustworthy  execution,  s;  be  a  state  in  a,  and  m\  :  tsslip  be  a  signed  slip  such 
that 

Si  |=  receive(M,  mi)  G  Hc. 

Since  messages  must  be  sent  before  they  are  received,  we  know  that 
Si  f=  send(C,  mi)  G  Hh. 

2.  An  occurrence  of  “send(C,  mi)”  could  have  resulted  only  from  an  application  of  Rm&’i  thus 

Si  \=  recei ve(iV,  mi)  G  HM. 

3.  From  Si  [=  receive (Ar, mi)  G  HM,  we  conclude  that  s,  )=  send(M,mi)  G  HN.  And  according  to 
T/vs,  Si  (=  commit(mi,  -)  G  HN. 

□ 

The  proof  of  Lemma  4.14  is  straightforward.  It  relies  on  the  fact  that  both  the  transaction 
request  and  the  transaction  slip  needed  by  M  to  claim  a  payment  are  needed  by  C  to  claim  the 
goods  in  court.  Note  that  even  though  we  assume  trustworthy  executions,  the  proof  does  not  need 
this  assumption. 

Lemma  4.14  Let  II  be  the  NetBill  protocol,  a  be  an  execution  in  E( U)m,  T  be  the  trust  assump¬ 
tions  II  makes,  and  PM  =  <&i  -+  □(($ci  V  $02)  -4  0($a/i  V  $M2))  be  M’s  protection  property  as 
specified  in  Section  4-3.2.  Then 

a  \=*  T  implies  a  |=*  -4-  m($c2  M2 )• 


Proof:  Let  0  =  s0  ei  si  ...  be  such  that  <7  \ =*  T  and  o  (=*  and  let  s,  be  a  state  in  o  such  that 
Si  |=  $C2-  The  following  shows  that  s,-  |=  4>m2- 

If  Si  |=  4>c2,  then  there  exists  a  message  mi  :  t.sslip  and  m2  :  tstr  such  that 

si  )=  commit  (mi,  m2)  G  HN  A  mi-msg.mid  =  <^>m.id  A 

vseal(mi.msg,  mi-sig,  Kn)  A  mi  .msg.res  A  mi  .msg.tid  ^0  A 

mi.msg.tid  =  m2.msg.sepo.msg.tid  A  ^  gs 

mi.msg.mid  =  m2.msg.mid  A  mi-.msg.cid  =  m2.msg.sepo.msg.cid  A 
m2.msg.mid  =  <^>m.id  A  m2.msg.sepo.msg.cid  =  ^>c.id  A 

vseal(m2.msg,  m2.sig,  <^m.key)  A  vseal(m2.msg.sepo.msg,  m2.msg.sepo.sig,  ^c-key) 

But  this  is  exactly  what  $M2  specifies. 
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□ 


4*6  Summary  and  Conclusion 

In  this  section,  we  summarize  the  findings  of  our  analysis  and  conclude  with  some  insights. 

4.6.1  Summary 

We  start  with  the  summary  in  Table  4.1.  All-protection  is  guaranteed  in  entries  with  a  y/\  certified 
delivery  is  needed  in  entries  with  a  *.  The  table  shows  that  NetBill  is  all-protective  under  all 
deviation  modes,  and  the  protection  does  not  rely  on  reliable  communication  channels.  It  also 
shows  that  the  certified  delivery  mechanism  is  needed  only  under  deception  mode. 


compliance 

abortion 

deception 

Channel  Failures 

V 

* 

No  Channel  Failures 

V 

V 

y/  * 

Table  4.1:  Summary  table. 


In  what  follows,  we  focus  on  each  of  the  entries  in  the  table. 

First,  it  is  not  surprising  that  all-protection  can  be  guaranteed  in  NetBill  without  reliable 
communication  channels.  This  is  so  because  neither  payment  nor  decryption  key  delivery,  which 
concludes  goods  delivery,  requires  reliable  communication  among  the  parties.  Payments  are  not 
communication-dependent  in  NetBill  because  they  are  funds  transfers  that  occur  at  the  NetBill 
server.  Key  deliveries  are  not  communication  dependent  because,  once  released,  keys  are  retained 
at  N ,  which  makes  them  always  accessible,  even  when  communication  channels  are  down. 

NetBill  is  all-protective  under  compliance  mode  because  payments  and  releases  of  decryption 
keys  happen  atomically  when  transactions  commit.  Since  everyone  behaves  compliantly,  funds 
are  actually  transferred  during  the  transaction  processing,  and  the  key  is  in  fact  the  right  one  for 
retrieving  the  goods.  Under  compliance  mode,  no  dispute  will  arise. 

For  the  same  reasons,  NetBill  is  all-protective  under  abortion  mode.  This  is  not  surprising. 
Premature  terminations  of  local  executions  can  happen  either  before  a  transaction  commits,  and 
prevent  it  from  committing;  or  after  it  has  committed.  In  the  first  case,  no  money  changes  hands 
and  no  key  is  released;  in  the  second  case,  the  exchange  has  taken  place.  All-protection  holds  in 
either  case.  Here  too,  no  dispute  will  arise. 

Under  deception  mode,  all-protection  can  no  longer  be  guaranteed  by  transaction  processing 
alone.  Certified  delivery  and  a  few  trust  assumptions  are  needed.  For  example,  if  M  deceives,  and 
encloses  a  bogus  key  in  the  transaction  request,  then  the  mere  atomic  swapping  of  the  ke}'  with  the 
money  does  not  protect  C’s  interests.  In  such  cases,  goods  cannot  be  retrieved  using  the  released 
key,  and  C  will  need  to  claim  them  in  court.  Unless  C  can  non-repudiably  show  that  she  was  not 
delivered  the  goods,  the  payment  will  not  bring  her  anything  in  return.  NetBill’s  certified  delivery 
mechanism  plays  a  critical  role  in  protecting  C° s  interests  here  because  it  enables  C  to  prove  what 
exactly  she  was  delivered.  Similarly,  N  can  deceive.  For  example,  it  can  release  the  key  enclosed 
in  the  transaction  request  without  transferring  funds  from  C  to  M.  In  such  cases,  M  will  need  to 
complain,  and  claim  the  payment  off-line.  Here  again,  NetBill’s  certified  delivery  mechanism  can 
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protect  M’s  interests.  It  enables  M  to  prove  that  he  actually  delivered  the  goods,  and  is  therefore 
entitled  to  payment.  Unless  M  can  non-repudiably  prove  that  he  actually  delivered  the  goods,  he 
may  risk  releasing  the  goods  for  nothing. 

These  examples  show  that  much  can  happen  after  a  protocol  execution  has  finished,  and  off-line 
arbitrations  can  remedy  anomalies  that  happen  on-line. 

Not  all  deceptions  can  be  remedied  by  certified  delivery  however;  some  cannot  be  easily  resolved 
and  can  compromise  C-protection  or  M-protection .  They  are  deceptions  that  violate  the  trust 
assumptions. 

During  our  modeling  and  analysis  exercise,  we  identified  a  number  of  trust  assumptions  for  N , 
the  NetBill  server.  These  assumptions  specify  what  N  must  not  do  in  order  to  guarantee  NetBill’s 
all-protection. 

First,  it  must  not  generate  unsigned  transaction  slips  ( Tn3 ).  Unsigned  slips  are  repudiable,  and 
therefore  not  useful  as  proofs  in  court.  When  releasing  unsigned  slips,  N  is  effectively  providing 
C  with  means  of  retrieving  the  goods,  if  the  right  decryption  key  is  enclosed,  without  assuring  M 
means  for  proving  this  in  court. 

Second,  N  must  not  generate  slips  with  corrupted  merchant  ids  (I/v4).  Transaction  slips  are 
vehicles  through  which  decryption  keys  are  released.  And  slips  with  corrupted  merchant  ids  are  typ¬ 
ically  unavailable  to  M.  Thus,  by  releasing  slips  with  corrupted  merchant  ids,  N  can  be  effectively 
giving  keys  to  C  behind  M’s  back. 

Finally,  N  must  not  generate  more  than  one  slip  per  transaction  (7VS).  A  transaction  slip 
provides  part  of  the  record  of  what  happens  with  a  transaction.  When  a  transaction  has  conflicting 
records,  disputes  are  hard  to  resolve.  In  practice,  the  existence  of  conflicting  records  may  favor 
those  that  do  not  need  much  else  to  make  their  cases.  For  example,  giving  M  a  slip  with  the  correct 
decryption  key  can  entitle  him  to  a  payment,  while  giving  C  a  slip  with  a  wrong  decryption  key 
alone  will  not  be  enough  for  her  to  claim  the  goods  in  court. 

Our  analysis  shows  that  NetBill  is  (^-protective  only  if  N  satisfies  T/v3  and  Tn4\  and  is  M- 
protective  only  if  N  satisfies  T/vs- 

4.6.2  Conclusion  and  Insights 

As  a  protocol  that  supports  dispute  resolution,  NetBill  brings  extra  challenge  to  the  specification 
of  its  protection  properties.  Since  the  protocol  offers  its  participants  ways  of  correcting  unfair 
outcomes  of  an  execution  after  the  fact  (this  is  the  notion  of  open  protection),  the  specifications 
need  to  take  into  account  not  only  on-line  exchanges  of  money  and  goods  between  the  customer 
and  the  merchant,  but  also  how  disputes  are  resolved.  In  the  context  of  a  protocol  where  non- 
repudiable  messages  collected  by  the  intermediary  are  used  to  resolve  disputes,  it  does  not  suffice 
to  know  what  messages  each  of  the  main  parties  has  access  to;  we  also  need  to  know  what  the 
intermediary  retained  and  is  willing  to  make  available.  This  explains  the  complexity  of  both  C’s 
and  M’s  protection  properties. 

Even  though  NetBill  is  all-protective,  it  only  guarantees  that  C  receives  what  M  set  out  to 
release,  which  may  not  be  what  C  expects  to  receive.  Unlike  Franklin  and  Reiter’s  protocol, 
NetBill  does  not  provide  means  for  C  to  check  whether  what  M  is  willing  to  release  is  indeed  what 
she  is  after.  Thus,  false  advertisements  would  need  to  be  dealt  with  outside  the  protocol. 

NetBill  treats  customers  and  merchants  differently.  It  is,  in  some  sense,  stricter  with  C  than 
with  M.  For  a  transaction  to  commit,  C  could  not  have  misbehaved  (assuming  that  N  does  not 
violate  the  trust  assumptions  and  M  behaves  compliantly).  M  however  can  misbehave:  he  may 
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not  forward  the  slip  back  to  C  or  he  may  release  a  bogus  key.  His  misbehaviors  are  dealt  with  after 
the  fact. 

Lastly,  the  set  of  trust  assumptions  we  identified  seems  to  have  captured  the  essence  of  being 
an  intermediary  in  NetBill,  even  though  it  is  unexpectedly  small.  Basically,  the  intermediary  is 
entrusted  to  handle  accounts  and  keys  honestly  (TV,  and  Ty2);  to  provide  unique  (TVS)  and  non- 
repudiable  ( TV3 )  proofs  of  what  happens  on-line;  and  to  allow  M  to  learn  what  really  happens 
with  the  transaction  (TVJ  so  that  keys  are  not  given  to  C  without  his  knowledge. 

Even  though  it  may  seem  counter-intuitive  at  first,  NetBill’s  all- protection  does  not  depend  on 
Ar’s  releasing  keys  that  M  sends  it,  or  ,/V’s  retaining  transaction  requests. 
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Chapter  5 

Brands’s  Off-line  Cash  with 
Observers  Protocol 


Our  last  case  study  is  Brands’s  untraceable,  off-line  cash  with  observers  protocol  [14],  henceforth 
referred  to  as  Brands’s  protocol.  This  case  study  is  the  most  interesting  for  three  reasons.  First,  we 
have  to  derive  an  abstract  version  of  the  protocol  from  its  purely  mathematical  formulation  [14]. 
This  exercise  is  challenging  because  the  protocol  is  very  complex  (not  only  compared  to  the  other 
two  protocols,  but  in  absolute  terms),  and  it  is  not  immediately  clear  how  abstract  we  should  model 
the  protocol. 

Second,  there  has  not  been,  to  our  knowledge,  analysis  of  electronic  cash  protocols  with  respect 
to  protection  of  individuals’  interests.  This  means  that  there  are  no  standard  protection  properties 
for  these  protocols,  and  we  have  to  propose  them  afresh. 

Finally,  our  analysis  reveals  a  number  of  weaknesses  in  the  protocol.  Some  of  the  weaknesses  are 
well-known  and  far  from  subtle;  for  example,  that  ecoins  can  get  lost  during  transmission.  Others, 
however,  are  quite  subtle,  and  have  not  been  found  before.  For  example,  a  payee  can  either  abort  or 
deceive,  and  effectively  make  the  payer’s  money  disappear,  even  if  communication  links  are  reliable. 
Also,  withdrawers  can  deceive,  and  withdraw  perfectly  valid  coins  that  they  can  spend,  but  will  be 
neither  accepted  for  deposit  nor  usable  for  tracing  the  identity  of  the  withdrawer.  Note  that  our 
analysis  results  only  apply  to  the  protocol  as  it  appears  in  [14].  In  fact,  none  of  the  weaknesses 
we  point  out  in  this  chapter  can  be  found  in  Brands’  later  designs  [15,  16].  (Readers  interested  in 
Brands’s  reaction  to  our  analysis  and  his  later  versions  of  the  protocol  should  go  to  Section  5.10.) 

In  this  chapter,  we  specify  the  protocol  in  our  specification  formalism  (Section  2.3),  and  analyze 
it  with  respect  to  protection  of  individuals’  interests  using  our  framework.  Since  we  are  interested 
in  protection  of  all  parties  equally,  we  analyze  it  with  respect  to  all- protection. 

The  rest  of  this  chapter  is  structured  as  follows.  In  Section  5.1,  we  introduce  basic  concepts 
associated  with  electronic  cash  systems.  In  Section  5.2,  we  introduce  the  protocol  and  assumptions 
made  by  Brands.  In  Section  5.3,  we  present  an  abstract  formulation  of  the  mathematical  building 
blocks  used  in  it.  In  Section  5.4,  we  formalize  the  protocol  and  its  protection  properties.  In 
Section  5.5,  we  prove  some  preliminary  results  needed  in  the  analysis  of  the  protocol.  In  Sections  5.6 
-  5.8,  we  analyze  the  withdrawal,  the  payment,  and  the  deposit  subprotocols  respectively.  In 
Section  5.9,  we  conclude  and  discuss  insights  gained  through  our  exercise.  Finally,  in  Section  5.10, 
we  include  Brands’s  comments  on  our  analysis. 
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5.1  Electronic  Cash  Systems  -  Preliminaries 

Electronic  cash  [25,  22,  23,  50,  62,  21,  24,  29,  14,  41,  40,  73,  72,  37],  henceforth  called  ecash,  was  first 
proposed  by  D.  Chaum  [21]  as  an  alternative  to  conventional,  account-based  electronic  payment 
schemes.  Unlike  in  account-based  schemes,  where  money  exists  solely  as  account  balances,  in  ecash 
systems  money  can  exist  in  the  form  of  digital  tokens  as  well.  This  feature  is  a  plus  from  the  point 
of  view  of  privacy:  while  payments  are  traceable  in  account-based  schemes,  they  are  untraceable 
in  ecash  systems.  Payments  are  traceable  in  account-based  schemes  because  they  are  direct  fund 
transfers,  and  account  managers  know  the  origin  (payer)  and  the  destination  (payee)  of  a  transfer. 
Payments  in  ecash  systems  are  untraceable  because  they  are  token  transfers  from  one  party  to 
another,  and  the  payer’s  identity  cannot  be  inferred  from  the  token  used  in  the  payment. 

In  what  follows,  we  use  ‘ecash’  to  refer  to  untraceable,  token-based  payment  schemes  and  the 
notion  of  ‘electronic  money’  in  general.  We  reserve  ‘ecoin’  (electronic  coin)  to  refer  to  the  token 
itself.  When  there  is  no  ambiguity,  we  also  use  ‘coin’  instead  of  ‘ecoin’. 

Ecash  is  not  a  perfect  counterpart  of  physical  cash.  Due  to  intrinsic  properties  of  the  electronic 
medium,  ecash  has  characteristics  of  its  own,  and  needs  to  rely  on  auxiliary  concepts  and  mecha¬ 
nisms  to  achieve  a  comparable  level  of  security.  For  example,  copying  ecoins  is  trivial,  and  unless 
additional  measures  are  taken,  one  can  double-spend  a  coin,  by  keeping  a  copy  of  a  coin  one  has 
already  spent  and  spending  it  again  later. 

Double-spending  is  a  problem  because  only  one  of  all  copies  of  a  coin  (the  one  accepted  by  the 
bank)  can  be  converted  back  to  physical  cash.  Thus,  effectively,  among  all  payees  of  a  double-spent 
coin,  only  one  will  get  paid,  even  though  all  of  them  received  the  coin.  Moreover,  since  ecoins  are 
untraceable,  the  remaining  payees  may  be  left  without  any  recourse. 

To  counteract  double-spending,  some  ecash  systems  [25]  take  an  on-line  approach,  in  which 
the  bank  keeps  the  status  (spent  or  not-yet-spent)  of  each  of  the  coins  in  the  system,  and  the 
payees  consult  the  bank  on-line  before  accepting  a  coin.  Double-spendings  are  impossible  in  on¬ 
line  systems  [30]. 

Brands’s  protocol  is  off-line.  Here  the  bank  is  not  consulted  before  coins  are  accepted.  To 
deal  with  double-spending,  Brands  uses  a  two-step  approach.  The  first  step  relies  on  observers 
and  tries  to  restrain  double-spending.  Observers  are  tamper-resistant  smartcards  attached  to  the 
payers’  systems,  and  are  entrusted  with  authorizing  coin  spendings.  They  restrain  double-spendings 
because  they  are  made  to  give  only  one  spending  authorization  per  coin.  Since  smartcards  are  not 
tamper-proof,  they  can  be  compromised,  and  authorize  multiple  spendings,  effectively  allowing  a 
coin  to  be  double-spent. 

The  second  step  works  remedially:  once  the  preventive  restraining  step  fails  and  a  double¬ 
spending  occurs,  the  protocol  tries  to  identify  the  double-spender.  The  intent  is  that  the  identifi¬ 
cation  will  enable  those  that  could  not  deposit  the  coin  to  go  after  the  double-spender,  and  claim 
a  real  payment.  (Note,  however,  that  malfunctioning  observers  do  not  always  authorize  multiple 
spendings;  they  may  not  authorize  any  spending  at  all,  and  effectively  lead  to  losses  of  coins.) 

Ecoins  themselves  are  untraceable;  thus  the  identification  mechanism  must  rely  on  something 
else.  In  Brands’s  protocol,  it  relies  on  rights  certificates,  which  we  introduce  in  Section  5.1.2. 

In  the  rest  of  this  section,  we  introduce  other  concepts  used  in  Brands’s  protocol. 


98 


5.1.1  Ecoins  and  Blind  Signature  Protocols 

Typically  implemented  as  digitally-signed  messages,  ecoins  can  be  abstractly  represented  as  pairs 
(u,  s)  of  substrate  u  and  signature  s.  Substrates  are  arbitrary  messages;  they  differ  from  one  coin 
to  another.  Signatures  are  digital  signatures  of  coin  issuer  on  the  substrates. 

To  achieve  untraceability,  substrates  are  typically  signed  using  blind  signature  schemes.  In 
blind  signature  schemes,  a  signature  s  signed  on  a  message  u  can  be  used  to  derive  a  signature 
s'  for  a  different  message  u' ,  derived  from  u.  Using  blind  signature  schemes,  one  can  effectively 
obtain  signatures  for  messages  that  the  signer  did  not  directly  sign. 

Fig.  5.1  depicts  an  abstract  blind  signature  protocol,  where  a  requester  R  obtains  from  a  signer 
S  a  blind  signature  for  message  m.  In  the  protocol,  blind  is  a  function  whose  inverse  is  unblind; 


1.  R-^  S  '.  bm  =  blind(m,  b) 

2.  S  —>  R  :  s  =  seal(bm,  k -1) 

The  various  symbols  denote: 

m  :  the  message  to  be  signed; 
b  :  a  randomly  generated  blinding  factor; 
k~1  :  5’s  signing  key. 

Figure  5.1:  An  abstract  blind  signature  protocol. 

b  is  a  randomly  generated  blinding  factor,  seal  is  a  signature  function;  k~ 1  is  5’s  signing  key;  and 
the  functions  are  such  that  unblind(s,  b)  equals  seal (m,  A:-1).  The  protocol  shows  that,  to  obtain  a 
blind  signature  for  m,  R  needs  to  send  5  a  blinded  message  (bm)  derived  from  m.  The  signature 
for  m  can  then  be  obtained  by  unblinding  the  signature  returned  by  5.  Effectively,  m  gets  signed, 
even  though  5  does  not  concretely  sign  it. 

Blind  signatures  guarantee  untraceability  because  5  cannot  link  the  signature  seal(m,  fc-1)  with 
R  even  if  it  keeps  a  record  of  all  signatures  it  issued  with  their  respective  requesters. 

5.1.2  Ecoins  and  Rights  Certificates 

Ecash  systems  that  rely  solely  on  ecoins  have  a  number  of  problems.  For  example,  they  allow 
double-spending  and  theft  (through  message  hijacking  or  eavesdropping). 

One  possible  solution  for  these  problems  is  to  make  ecoins  themselves  worthless  unless  accom¬ 
panied  by  rights  certificates.  Rights  certificates  are  coin-specific  and  payee-specific,  and  are  used 
by  a  payer  to  give  the  rights  of  a  coin  to  a  payee.  If  the  withdrawer  of  a  coin  (a.k.a.  payer)  were 
the  only  one  able  to  provide  rights  certificates  for  it,  then  no  one  other  than  the  withdrawer  would 
be  able  to  spend  the  coin,  and  potential  hijackers  that  seize  the  coin,  while  it  is  in  transit  between 
the  bank  and  the  withdrawer,  would  have  no  way  of  profiting  from  the  hijacking.  If,  in  addition, 
the  withdrawer  were  able  to  provide  at  most  one  rights  certificate  per  coin,  then  double-spending 
would  not  be  possible.  Finally,  if  the  bank  deposits  a  coin  only  when  it  is  accompanied  by  a  rights 
certificate  indicating  the  depositor  (a.k.a.  payee)  as  a  lawful  holder  of  the  coin,  then  coin  hijackings 
between  a  payer  and  a  payee,  or  between  a  depositor  and  the  bank  would  also  be  non-profitable. 
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Brands  takes  exactly  this  approach;  his  implementation  of  rights  certificates  appears  in  Sec¬ 
tion  5.2.3. 

In  addition  to  transferring  rights,  counteracting  theft,  and  restraining  double-spendings,  rights 
certificates  play  a  pivotal  role  in  tracing  the  identity  of  double-spenders  in  Brands’s  protocol. 
In  Brands’s  protocol,  the  number  of  rights  certificates  a  withdrawer  is  able  to  issue  per  coin  is 
controlled  by  the  observer.  If  the  observer  is  compromised,  double-spending  becomes  a  problem. 
Rights  certificates,  however,  embed  identification  information  about  the  withdrawer  of  a  coin. 
They  are  designed  in  such  a  way  that  a  single  certificate  would  not  yield  any  information  about  the 
identity  of  the  withdrawer,  but  two  different  certificates  of  a  coin  would  allow  the  bank  to  reveal 
this  information.  When  a  coin  is  double-spent,  each  of  the  payees  receives  a  different  certificate. 
When  more  than  one  of  them  submits  the  coin  for  deposit,  the  bank  can  reveal  the  identity  of  the 
double-spender  using  the  accompanying  certificates. 

5,2  Brands’s  Protocol  —  An  Introduction 

Brands’s  protocol  requires  four  principals:  a  payer  P,  a  payee  JS,  a  bank  B,  and  an  observer 
O.  In  the  rest  of  this  chapter,  P  will  be  referred  to  as  she,  E  as  he,  and  B  and  O  as  it.  B 
keeps  accounts  for  both  P  and  P,  can  issue  coins,  and  can  receive  them  back  in  deposits.  In  this 
protocol,  B  issues  coins  of  only  one  denomination.  P  can  withdraw  coins  from  her  account  and 
use  them  in  payments.  E  can  receive  coins  from  P  and  deposit  them  into  his  account.  O,  in  its 
turn,  participates  in  the  generation  of  substrates  and  rights  certificates,  and  plays  a  pivotal  role  in 
restraining  P  from  double-spending. 

In  this  section,  we  introduce  Brands’s  protocol,  which  consists  of  three  subprotocols:  with¬ 
drawal,  payment,  and  deposit.  The  version  presented  here  is  an  abstraction  of  the  one  given 
in  [14],  and  will  be  used  in  our  analysis.  Our  presentation  here  is  informal.  See  Section  5.4  for  a 
formal  specification  of  the  protocol,  and  Section  5.3  for  an  abstract,  but  precise,  definition  of  the 
cryptographic  functions  and  predicates  we  use.  We  do  not  transcribe  the  concrete  protocol  here; 
interested  readers  should  refer  to  [14]  directly.  In  what  follows,  we  first  present  the  setup  of  the 
system,  then  describe  each  of  the  subprotocols. 

Notation 

In  Brands’s  protocol,  principals  hold  secrets  and  show  knowledge  of  their  secrets  throughout  the 
protocol.  Since  secrets  are  not  to  be  revealed,  Brands  has  secret  holders  show  their  knowledge  of 
a  secret  by  showing  the  value  of  the  application  of  a  one-way  function  to  the  secret.  The  protocol 
thus  uses  a  number  of  different  publicly  known  and  agreed  upon  one-way  functions  whose  sole 
purpose  is  to  mask  secrets. 

We  use  lowercase  Greek  letters  to  denote  secrets,  and  7  (overlining)  to  denote  their  one-way 
functions.  Note  that  we  do  not  distinguish  different  one-way  functions;  we  represent  them  all  by 
7.  Secrets  have  subscripts  indicating  to  whom  they  belong.  Sometimes,  integer  subscripts  are  used 
to  number  them.  For  example,  62o  denotes  a  secret  belonged  to  the  observer,  while  Op  denotes  a 
one-way  function  of  a  secret  belonged  to  the  payer. 

Some  one-way  functions  have  standard,  distinguished  names,  ‘blind’  (without  the  quote  marks) 
is  an  example. 
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5.2.1  The  Setup  of  the  System 

P  has  two  databases:  an  account  database  for  information  about  account  holders;  and  a  deposit 
database  for  deposit  transcripts.  B  also  has  a  public  key  pair,  k~l  (private  key)  and  k  (public  key), 
which  it  uses  for  signature  generation  and  verification.  Both  P  and  P  also  have  k.  Finally  B  has 
a  collection  of  smartcards. 

To  open  an  account,  P  generates  a  random  number  0p  and  its  corresponding  one-way  function 
!Tp.  9V  is  kept  private  at  P,  while  Tp  is  sent  to  B.  B  checks  0P  for  uniqueness  before  accepting  it  as 
P’s  account  number. 

Once  B  accepts  6P  as  P’s  account  number,  it  chooses  a  smartcard  O,  and  initializes  it  by  writing 
a  randomly  generated  number  60  to  its  ROM.  B  then  creates  an  entry  ( ip ,  6P ,  80 ),  where  ip  is  P’s 
id,  in  the  account  database;  computes  T0  ;  and  gives  both  O  and  60  to  P.  O  is  from  now  on  P’s 
observer.  Fig.  5.2  shows  what  each  of  the  principals  has  once  the  system  is  set  up.  Note  that 
P’s  entry  in  P’s  account  database  has  less  information  than  P’s  entry  has.  This  difference  reflects 
the  fact  that  the  system  can  accommodate  two  types  of  accounts:  those  from  which  coins  can  be 
withdrawn  (P’s  account)  and  those  that  cannot  (P’s  account). 


B:l 


•  an  account  database  including  the  two  entries  below: 

*  «e,  _ 

•  a  deposit  database; 

•  a  public  key  pair  (Af"1,  k ). 


P:< 


•  P’s  public  key  k] 

•  Op] 

•  0o ; 


•  i 


p* 


P: 


•  P’s  public  key  k ; 

•  ie- 


O  : 


{ 


•  o0. 


The  various  symbols  denote: 

ip,  ie  :  P’s  id  and  £”s  id,  respectively; 
6P  :  P’s  account  secret; 

0o  :  O’s  secret. 


Figure  5.2:  What  the  principals  have  once  the  system  is  set  up. 

Brands  makes  a  few  assumptions  for  the  setup  of  the  system.  He  assumes  that  smartcards’ 
ROMs  cannot  be  read  directly,  except  by  O,  and  can  be  written  only  by  B.  He  also  assumes  that 
initial  exchanges  described  above  can  be  securely  and  correctly  carried  out  between  P  and  B. 
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In  the  protocol,  6P  is  P’s  account  secret.  It  appears  in  all  the  coins  withdrawn  from  P’s 
account,  and  is  the  information  revealed  by  B  if  P  double-spends.  60  is  the  observer  secret.  Like 
6P,  it  appears  in  all  the  coins  withdrawn  from  P’s  account.  Note  that  0o  is  known  only  to  B  and 
O.  P  cannot  learn  the  value  of  0o  because  she  cannot  read  O’ s  ROM  and  cannot  retrieve  60  from 

T0. 

5.2.2  The  Withdrawal  Protocol 

Brands’s  withdrawal  protocol  (Fig.  5.3)  is  in  its  core  (steps  3  and  4)  a  blind  signature  protocol 
(Fig.  5.1.1)  where  B  blindly  signs  the  substrate  («i,  u2)  of  the  coin  being  withdrawn.  Since  («i,  ^2) 
is  being  blindly  signed,  it  is  blinded  by  a  randomly  generated  blinding  factor  f3p  before  it  is  sent 
for  signature  (step  3),  and  the  signature  itself  can  be  obtained  by  unblinding  the  value  si  returned 
by  B  (step  4).  At  the  end  of  the  protocol,  (( u\,u2 )i  unblind($/,  (3P ))  is  the  coin  withdrawn  by  P. 


1.  P  -4  O  :  secret-request 

2.  O^P:  TT0 

3.  P  B  :  bu  =  blind((ui,u2),  Pp) 


where 


ui  =  subsi  (0P,  vip,  0o),  and 

u2  =  subs2{vip,v2p,0o,TO), 


4.  B  — >  P  :  si  =  seal(bu,6p,0o,k  x) 


The  various  symbols  denote: 

secret-request :  a  pre-defined  message  for  requesting  a  secret  from  O; 
v0,vip,v2p  :  randomly  generated  secrets; 

0P,  0o  :  P’s  account  secret  and  O’s  secret,  respectively; 

Pp  :  a  randomly  generated  blinding  factor; 
k~l  :  P’s  private  key. 


Figure  5.3:  The  withdrawal  protocol. 

Besides  this  core  structure,  two  other  features  deserve  attention  in  this  protocol.  First,  the 
substrate  (ui,u2),  where 

{«i  =  subsi{6p,vip,60),  and 
u2  =  subs2(ulp,u2p,0o,l^), 

is  a  pair  whose  elements  are  functions  (subsi  and  subs2)  of  two  sets  of  values.  The  first  set  is 
account  specific  and  consists  of  0p  and  0o,  which  are  available  to  P  once  the  system  is  set  up.  They 
encode  information  about  respectively  which  account  the  coin  is  withdrawn  from  and  who  is  the 
observer.  The  second  set  is  coin-specific  and  consists  of  vlp,  v2p,  and  TO,  which  are  all  randomly 
generated  during  the  withdrawal  protocol.  While  i/lp  and  v2p  are  locally  generated  by  P,  TO  is 
provided  by  O  under  P’s  request  (steps  1  and  2).  O’s  participation  towards  building  the  substrate 
enables  it  to  control  the  spending  of  the  coin  later  in  the  payment  protocol.  We  explain  the  control 
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mechanism  in  Section  5.2.3.  subsi  and  subs2  are  two  one-way  functions  named  to  suggest  that  they 
produce  respectively  the  first  and  the  second  components  of  a  substrate. 

Second,  the  signature  function  (seal)  used  by  B  differs  from  the  basic  version  shown  in  Fig.  5.1: 
si  is  a  function  not  only  of  blinded  message  bu  and  P’s  private  key  A:-1,  but  also  of  two  other  values 
Tp  and  T0,  that  B  retrieves  from  P’s  entry  in  the  account  database.  This  signature  function  is  such 
that  a  signature  is  valid  only  if  it  embeds  the  right  private  key,  and  6P  and  60  are  exactly  those 
embedded  in  bu.  Thus,  unless  P  embeds  the  correct  account  and  observer  information  into  the 
substrate,  the  signature  returned  by  B  will  not  be  valid,  and  P  will  not  have  obtained  a  coin.  This 
effectively  protects  the  system  from  P’s  misbehaving.  6P  and  0o ,  now  embedded  in  the  substrate, 
will  later  appear  in  the  coin’s  rights  certificates,  and  be  used  to  trace  a  double-spent  coin  back  to 
P.  By  ensuring  that  only  correct  “origin”  information  is  embedded  in  valid  coins,  Brands  seeks  to 
ensure  that  double-spenders  will  always  be  unmistakenly  identified. 

Finally,  B  debits  P’s  account  before  sending  si  to  P.  This  is  not  shown  in  Fig  5.3  because  we 
omit  internal  actions  in  this  informal  presentation. 

r 

5.2.3  The  Payment  Protocol 

Brands’s  payment  protocol  (Fig.  5.4)  consists  of  two  nested  protocols.  In  the  outer  one  (steps  1,  2 
and  5),  P  gives  E  the  coin  c  (whose  substrate  is  as  specified  in  Section  5.2.2)  and  an  accompanying 
rights  certificate  rcp;  in  the  inner  one  (steps  3  and  4),  P  obtains  the  help  she  needs  from  O  to 
generate  the  certificate. 


1. 

P^E: 

c  =  ((uuu2),us) 

2. 

£4  P  : 

ch  =  chal(ie,t ) 

3. 

P-^O  : 

ch 

4. 

0-4P: 

rc0  =  pcert(ch,  90,  u0) 

5. 

P->  E  : 

rcp  =  rcert(rca,  0P,  ulp,  v2p) 

The  various  symbols  denote: 


c 

ie 

t 

ch 

Vo  j  V\p ,  V2p 
8P,60 
rc0 
rcp 


a  coin  whose  substrate  (zii,w2)  is  as  specified  in  Section  5.2.2; 
P’s  id; 

a  challenge  seed; 
a  challenge; 

secrets  found  in  (^i,  w2); 

P’s  account  secret  and  O’ s  secret,  respectively; 
a  protocertificate; 
a  rights  certificate. 


Figure  5.4:  The  payment  protocol. 

As  shown  in  Fig.  5.4,  rcp  is  a  response  to  the  challenges  ch  presented  by  E.  It  embeds  not 
only  the  challenge  itself,  but  also  the  secrets  embedded  in  the  coin’s  substrate  (note  that  rcv  is  a 
function  of  0p,  vip,  z^2p,  and  rc0,  which,  in  its  turn,  is  a  function  of  eft,  0o  and  v0).  rcp  is  payee- 
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specific  because  it  is  a.  function  of  ch,  which  is  a  function  of  the  payee’s  id  ie.  rcp  is  coin-specific 
because  it  embeds  coin-specific  secrets  -  u0,  i/lp,  and  v2p  -  found  in  the  coins’  substrate. 

Note  that  P  is  unable  to  provide  the  certificate  herself:  the  substrate  embeds  two  secrets  -  60 
and  v0  -  whose  values  are  known  only  to  O.  The  inner  protocol  now  comes  into  play:  it  allows  P  to 
request  and  receive  O’s  help  with  these  values.  P  never  learns  the  values  of  these  secrets,  however, 
because  O  embeds  them  in  rc0  -  henceforth  called  a  protocertificate  -  rather  than  providing  them 
in  clear.  Control  of  these  secrets  gives  O  control  of  generation  of  certificates,  and  ultimately  of 
coin  spending.  Because  O  is  designed  to  erase  v0  once  it  has  been  used  towards  generating  a 
protocertificate,  P  will  not  be  able  to  provide  a  second  rights  certificate  for  the  coin.  The  coin 
therefore  cannot  be  double-spent.  If  O,  however,  is  tampered  with  and  does  not  erase  v0,  it  will 
successfully  provide  P  with  another  protocertificate  the  next  time  it  is  presented  a  challenge.  This 
would  enable  P  to  provide  a  second  rights  certificate  for  the  coin  and  double-spend  it.  Finally,  no 
one  other  than  P  and  O  (jointly)  can  provide  a  certificate:  P  is  the  only  one  that  knows  the  value 
of  the  remaining  secrets  ( 6p ,  z/lp,  and  v2p). 

In  Fig.  5.4,  function  chal's  second  argument  t  is  a  locally  unique  value  that  differs  from  one 
transaction  to  another.  This  transaction-specificity  serves  two  purposes.  First,  it  prevents  replays 
of  both  rcQ  and  rcp.  Second,  it  enables  traceability  of  double-spenders:  the  deposit  protocol  (Sec¬ 
tion  5.2.4)  hinges  on  having  different  rights  certificates  for  different  spendings  of  a  coin  to  reveal 
the  identity  of  a  double-spender.  Note  that  we  use  t,  instead  of  a  lowercase  Greek  letter  (reserved 
for  values  that  are  to  be  kept  secret),  to  denote  this  value.  This  indicates  that  t  does  not  need  to 
be  randomly  generated  or  kept  secret.  In  fact,  the  date  and  the  time  of  a  payment  are  a  perfect 
candidate  for  t.  Since  these  Ps  are  used  to  generate  challenges,  we  call  them  challenge  seeds. 

Before  accepting  the  payment,  E  carries  out  two  verifications.  First,  he  verifies  whether  the 
coin  is  valid,  i.e.,  whether  it  has  a  valid  signature  from  B.  Then  he  verifies  whether  the  rights 
certificate  is  valid,  i.e.,  whether  rcp  embeds  the  challenge  he  sent  and  the  secrets  embedded  in  the 
coin’s  substrate  («i,  u2).  Note  that  E  can  verify  the  consistency  between  the  secrets  embedded  in 
(«i,  u2)  with  those  embedded  in  rcp  only  indirectly ,  because  subsj,  subs2,  and  certp  are  all  one-way 
functions,  and  E  learns  neither  the  actual  secrets  embedded  in  («i,  u2)  nor  those  embedded  in  rcp. 

The  same  observation  applies  to  P’s  verification  of  rc0’s  validity,  where  P  checks  the  value  of 
rc0  against  those  of  0o  and  IT 

Indirect  verifications  are  customary  in  cryptography.  Public  key  signature  verification  is  an 
example  where  the  verifier  can  check  the  validity  of  a  signature  indirectly,  without  learning  the 
value  of  the  signing  private  key. 

5.2.4  The  Deposit  Protocol 

To  deposit  a  coin  c  (Fig.  5.5),  E  sends  B  the  coin  itself,  an  accompanying  rights  certificate  rcp, 
and  the  challenge  seed  t.  he  used  to  generate  the  challenge  embedded  in  rcp. 

Before  accepting  c  for  deposit,  B  carries  out  three  verifications.  First,  it  verifies  whether  c  has 
P’s  signature  on  it.  Second,  it  verifies  whether  rcp  is  a  valid  rights  certificate  giving  E  the  rights  to 
c.  To  do  this  verification,  B  first  generates,  using  P’s  id  and  t,  the  challenge  that  was  supposedly 
used  by  E  in  the  payment  protocol.  Using  this  challenge  and  c’s  substrate,  B  can  now  verify  the 
validity  of  rcp.  Like  P  in  the  payment  protocol,  B  can  dp  this  verification  only  indirectly,  because  it 
knows  neither  the  secrets  embedded  in  the  substrate  nor  those  embedded  in  rcp.  Lastly,  B  verifies 
whether  c  has  been  deposited  before.  For  this  verification,  B  searches  its  deposit  database.  If  c 
has  been  deposited  before,  the  first  component  U\  of  its  substrate  will  be  found  in  the  database. 


104 


1.  E  B  :  c,t,  rcp 

The  various  symbols  denote: 
c  :  a  coin; 

rcp  :  c’s  accompanying  rights  certificate; 
t  :  challenge  seed  that  appear  in  rcp. 


Figure  5.5:  The  deposit  protocol. 

If  either  of  the  first  two  verifications  fail  (c  is  not  a  valid  coin  or  rcp  is  not  a  valid  rights  certificate 
giving  E  the  rights  to  c),  B  simply  ignores  this  deposit  attempt. 

If  the  first  two  verifications  succeed,  but  the  third  one  fails  (c  is  a  valid  coin,  has  not  been 
deposited  before,  and  E  has  the  rights  to  it),  B  accepts  the  coin  for  deposit.  In  a  deposit,  B  credits 
P’s  account  and  creates  a  new  entry  in  the  deposit  database.  The  new  entry  consists  of  u\,  the 
challenge  chal(ie,t ),  and  rcp.  Note  that  the  second  component  u2  of  the  substrate  is  left  out  of  the 
database  for  efficiency  reasons.  The  assumption  here  is  that  two  substrates  that  share  their  first 
components  also  share  their  second. 

If  all  three  verifications  succeed  (P  was  given  the  rights  to  a  valid  coin  that  has  been  deposited 
before),  then  there  is  an  entry  in  P’s  deposit  database  for  c,  and  a  fraud  is  flagged.  Either  P 
or  E  can  be  the  fraudulent  party.  If  the  challenge  in  the  database  entry  equals  the  one  from  the 
current  deposit  attempt,  E  is  trying  to  double-deposit  the  coin;  otherwise,  P  has  responded  to 
two  different  challenges,  and  has  double-spent  the  coin.  In  the  first  case,  B  does  not  take  further 
action,  because  P’s  attempted  fraud  has  been  detected  and  no  one  was  hurt.  In  the  second  case, 
E  is  left  with  a  coin  that  cannot  be  deposited;  effectively  he  was  not  paid. 

Here  is  where  traceability  of  double-spenders  comes  to  the  rescue.  Using  the  rights  certificate 
found  in  the  database  entry  submitted  when  c  was  first  deposited  and  the  one  submitted  with  the 
current  deposit  attempt,  B  can  retrieve  derive  0p,  and  obtain  P’s  identity  ip.  These  two  rights 
certificates  are  necessarily  different  because  challenges  they  embed  are  different. 

5,2.5  Assumptions 

Brands’s  paper  is  specific  in  how  it  addresses  various  assumptions  needed  by  the  protocol.  While 
it  includes  a  good  amount  of  discussion  about  cryptographic  assumptions  that  the  protocol  relies 
on,  it  fails  to  provide  a  satisfactory  account  of  system-related  assumptions.  In  fact,  there  is  no 
mention  as  to  whether  communication  links  can  fail,  or  how  exactly  different  participants  can  fail 
or  misbehave. 

One  can  infer  that  he  implicitly  assumes  reliable  communication  links;  however,  there  does  not 
seem  to  be  a  consistent  model  of  the  protocol  participants  themselves.  For  example,  P’s  attacks 
to  the  protocol  seem  restricted  to  double-spending  and  analyzing  messages  from  B  and  O  in  order 
to  forge  coins.  P’s  attacks  seem  restricted  to  double-depositing.  Conversely,  being  able  to  spend 
a  coin  she  withdraws  and  assuring  her  privacy  (that  her  payments  will  not  be  traceable  unless  she 
double-spends)  seem  to  be  P’s  main  concerns.  Whether  or  not  she  could  lose  a  coin  while  trying 
to  spend  it  seems  irrelevant.  Except  for  double-spending  and  double-depositing,  all  the  attacks  he 
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considers  are  cryptographic  in  nature. 

We  attribute  this  inconsistency  to  the  nature  of  the  work.  Brands  is  focused  on  using  novel 
cryptographic  primitives  to  formulate  a  novel  protocol.  It  is  understandable  that  he  is  primarily 
concerned  with  cryptography.  However,  his  neglect  of  system-  and  protocol-level  issues  has  impact 
on  the  protocol’s  overall  security,  as  it  will  become  apparent  from  our  analysis. 


5.3  Abstract  Formulation  of  the  Building  Blocks 

5.3.1  Cryptographic  Building  Blocks 

Brands’s  protocol  [14]  uses  a  number  of  cryptographic  building  blocks.  They  are  abstractly  repre¬ 
sented  in  our  introduction  to  the  protocol  in  Section  5.2.  In  this  subsection,  we  present  an  abstract 
formulation  of  these  building  blocks.  We  start  with  an  informal  introduction;  the  formalization 
appears  in  Def.  5.1.  In  what  follows,  =  denotes  conversion. 

All  arithmetic  in  Brands’s  protocol  is  performed  in  groups  of  prime  order  for  which  polynomial¬ 
time  algorithms  are  known  for  multiplication,  inversion,  equality  test,  membership  test,  and  random 
selection  of  elements.  We  use  type  t.nurn  to  represent  such  groups  in  our  abstraction,  and  refer  to 
their  elements  simply  as  numbers. 

One-way  functions  are  widely  used  in  Brands’s  protocol  to  generate  secret-embedding  messages. 
Some  of  these  messages  have  special  meanings,  while  others  do  not.  One-way  functions  that 
generate  the  former  appear  below;  those  that  generate  the  latter  are  represented  simply  as  '. 

The  first  two  functions,  subsi  and  subs2,  are  used  to  generate  respectively  the  first  and  the 
second  components  of  coin  substrates,  subsi  takes  three  arguments,  while  subs2  takes  four.  The 
arguments  need  to  satisfy  the  following  relation:  Let  nj, . .  .,»7  be  seven  numbers, 


(subsi(??i ,...,  n3),  subs2(n4, ...,  n7))  is  a  substrate  if  and  only  if  <  n<1  n4>and 

[  «3  =  n6. 

The  other  numbers  do  not  need  to  relate  to  each  other  in  any  specific  way.  Some  of  them  need  to 
be  drawn  from  specific  sources  (Section  5.2.2),  however. 

To  generate  a  coin,  substrates  are  blindly  signed  using  public  key  cryptography.  In  public  key 
crypto-systems,  private  and  public  keys  come  in  pairs.  If  A:-1  and  k  are  respectively  the  private 
key  and  the  public  key  of  a  key  pair,  then  they  satisfy  the  predicate  keyPair.  That  is 

keyPair(A;-1,  k)  =  true. 


Given  a  substrate  u  —  (subsi(«i,  — ,  rc2),  subs2(— ,  — ,  7i2,  — )),  where  stands  for  arguments 
whose  actual  values  are  irrelevant  in  the  context,  and  a.  private  key  A;-1, 

seal(u,  n\, n2,  A:-1) 

denotes  the  signature  of  A:-1  on  u.  Note  that  seal  is  an  non-standard  signing  function  here;  the 
signature  is  a  function  not  only  of  the  substrate  and  the  private  key,  but  also  of  two  numbers 
embedded  in  the  substrate.  Signatures  can  be  verified  using  public  keys;  predicate  vseal  models 
signature  verification.  Given  a  substrate  u,  a  signature  s ,  and  public  key  k , 

vseal (tt,  s,  k)  =  true 
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if  and  only  if  s  is  a  signature  of  k~l  on  u,  and  k  1  is  the  private  counterpart  of  k. 

Messages  can  be  blinded.  Given  a  message  m  and  a  number  b , 

blind  (m,  b ) 

denotes  the  result  of  blinding  m  with  b.  The  corresponding  unblinding  function, 

unblind  (m,  b) 

denotes  the  result  of  unblinding  m  with  b.  For  all  blinded  messages  m'  =  blind  (m,  b)  and  numbers 
b' ,  unblind  (blind  (m,  b),  b')  =  m,  if  b  =  6'.  That  is, 

unblind  (blind  (m,  b) ,  b)  =  to. 

Unblinding  commutes  with  signing.  Given  a  message  seal(«,  «i,  n2,  h_1)  and  a  number  6, 

unblind(seal(u,ni,ra2,h_1),h)  =  seal  (unblind  (w,  b),  nh  n2,  k"1). 

Note  that  both  blind  and  unblind  are  polymorphic  functions. 

To  generate  challenges  for  rights  certificates,  we  need  a  type  that  can  provide  different  values 
for  different  transactions.  Let  Lcs  denote  such  a  type.  Then,  given  a  principal  id  id  and  an  element 
c  from  t.cs, 

dial  (id,  c) 

denotes  a  challenge. 

To  generate  a  rights  certificate,  one  needs  a  protocertificate.  Given  a  challenge  ch  and  two 
numbers  n\  and  n2, 

pcert  (ch,  ni,  n2) 

is  a  protocertificate.  One  can  indirectly  check  the  values  embedded  in  a  protocertificate;  predicate 
vcert0  models  this  check.  Given  a  protocertificate  p,  a  challenge  ch,  and  two  numbers  n\  and  ra2, 

vpcert(p,  ch,  »i,  n2)  =  true 

if  and  only  if  p  is  consistent  with  ch,  »i,  and  n2.  The  consistency  condition  is  given  in  Def.  5.1. 
Given  a  protocertificate  p  and  numbers  n\,  n2,  and  «3, 

rcert(p,  »i,  n2,  n3) 

denotes  a  rights  certificate.  Rights  certificates  can  be  checked  against  a  challenge  and  a  substrate. 
Predicate  vcertp  models  this  check:  given  a  rights  certificate  rc,  a  challenge  ch,  and  a  substrate  u, 

vrcert( rc,  ch,  u )  =  true 

if  and  only  if  the  values  embedded  in  rc  are  consistent  with  ch  and  those  embedded  in  u. 

Finally,  two  different  rights  certificates  of  a  coin  can  be  used  to  reveal  the  account  secret 
embedded  in  the  coin.  We  use  reveal_sec  to  denote  the  secret  revelation  function.  Let  rc  and  rc' 
be  two  different  rights  certificates  of  a  coin  c,  and  n  be  a  number, 

reveal_sec(rc,  rc',  n ) 

corresponds  to  the  account  secret  embedded  in  c,  if  n  is  the  observer  secret  embedded  in  c. 

In  Def.  5.1,  we  list  the  cryptographic  building  blocks  as  well  as  their  abstract  properties: 
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Definition  5,1  Cryptographic  building  blocks 

1.  Numbers  have  type  t.num ,  i.e.,  if  m  is  a  number ,  then  m:  t.num; 

2.  Component  one  of  substrates  have  type  t.subsi,  i.e.,  if  in  is  a  value  of  function  subsi,  then 
m:  t.subsi ; 

3.  Component  two  of  substrates  have  type  t.subs2,  i.e.,  if  m  is  a  value  of  function  subs2,  then 
m:  t.subs2; 

4 ■  Private  keys  have  type  Lprik,  i.e.,  if  m  is  a  private  key,  then  m:  t.prik; 

5.  Public  keys  have  type  t.pubk ,  i.e.,  if  m  is  a  public  key,  then  m:  Lpubk; 

6.  Signatures  have  type  t.seal,  i.e.,  if  m  is  a  value  of  function  seal,  then  m:  t.seal ; 

7.  Principal  ids  have  type  t.id;  i.e.,  if  m  is  a  principal  id,  then  m:  t.id; 

8.  Challenge  seeds  have  type  t.cs,  i.e.,  if  m  is  a  challenge  seed,  then  m:  t.cs; 

9.  Challenges  have  type  t.chal,  i.e.,  if  m  is  a  value  of  function  chal,  then  m:  t.chal; 

10.  Protocertificates  have  type  t.pcert,  i.e.,  if  m  is  a  value  of  function  pcert,  then  m:  t.pcert; 

11.  Rights  certificates  have  type  t.rcert,  i.e.,  if  m  is  a  value  of  function  rcert,  then  m:  t.rcert; 

12.  Functions  and  predicates: 

•  T:  t.num,  — >  t.num; 

•  subsi:  t.num  x  t-num  x  t-num  — >  tsubs\; 

•  subs2:  t.num,  x  t-num,  X  t-num  x  t-num  tsubs2; 

•  keyPair:  tjprik  x  Cpubk  ^  boolean; 

•  seal:  ( tsubsi  x  tsubs2 )  x  t-num  X  t-num  x  t-prik  -4  t.seal; 

•  vseal:  (tsubsi  x  t.subs2 )  x  t.seal  x  t.pubk  — >  boolean; 

•  blind:  x  x  t.num  -4  x,  where  x  is  a  type  variable; 

•  unblind :  x  x  t.num  -4  x,  where  x  is  a  type  variable; 

•  chal:  t.id  x  t.cs  -4  t.chal ; 

•  pcert:  t.chal  x  t.num  x  t.num  -4  t.pcert; 

•  rcert:  t.pcert  x  t.num  X  t.num,  x  t.num  -4  t.rcert; 

•  vpcert:  t.pcert  x  t.chal  x  t.num  X  t.num  -4  boolean; 

•  vrcert :  t.rcert  x  t.chal  X  (t.subsi  x  t.subs2)  -4  boolean; 

•  revealsec:  t.rcert  x  t.rcert  x  t.num  -4  t.num; 

13.  Conversion  rules: 

•  unblind(blind(m,  b),  b ')  -  m,  if  and  only  if  b  —  bf ; 
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•  unblind($eal(u,  n\,  n2,k  *),  b)  =  seal(unblind(u,  b),  rii,  n2,  k  *); 

true ,  if3ni,ri2  :  t.num  and  k “1:  t-prik  such  that 

u=  (subs1(ni)-,n2),subs2(-,-,n2,-))  A 
s  =  seal(u,  ni,  722,  &_1)  A  fceyPazr(Ar_1,  fc); 
false,  otherwise. 

vseal(u,  s ,  k)  is  true  if  and  only  if  numbers  n\  and  n2  embedded  in  the  signature  are 
also  embedded  in  the  substrate,  and  the  signing  key  is  the  private  counterpart  of  the 
verification  key. 


vseal(u,  s,  k )  = 


•  vpcert{p,ch,ni,n2) 


true,  if  3 n[ ,  nf2  :  t_num  such  that 
<  n[  =  n\  A  n'2  =  n2  A  p  =  pcert(ch:  n[,  n'2); 

false,  otherwise. 


vpcert(p,  ch,  n\,  n2)  is  true  if  and  only  if  p  embeds  ch  and  the  secrets  embedded  in  n\ 
and  n2 . 


•  vrcert(r ,  ch ,  u ) 


true,  if  3n\ , . . . ,  725  :  t.num  such  that 

r  =  rcert(pcert(ch ,  ni,  722),  723,  rc4,  ns)  A 
u  =  (sutai(n3,  724, 7TT),  5w652(n4,  n5,  nT,  n^)); 
/a/se;  otherwise. 


vrcert(r,  ch,  u)  is  true  if  and  only  if  r  embeds  ch  and  all  the  secrets  embedded  in  u. 


•  Let 

r  =  rcert(pcert(ch ,  ni,  n2),  723,  724, 725)  and  r'  =  rcert(pcert(chf ,  721,  ti2),  723, 724, 725) 
be  two  rights  certificates. 

reveaLsec{r ,  r',  721)  =  723,  7/  cmd  on/?/  if  ch  7^  eft'. 

0726  can  reveal  the  coin’s  account  secret  (723)  if  and  only  if  one  has  two  different  rights 
certificates  of  a  coin  ( note  that  both  r  and  d  refer  to  the  same  substrate,  but  are  responses 
to  different  challenges )  and  the  coin’s  observer  secret  (721). 


5.3.2  Product  Types  and  Projection  Functions 

Some  composite  messages  have  special  semantics  in  Brands’s  protocol.  For  example,  substrates 
are  ordered  pairs,  and  each  entry  in  the  bank’s  deposit  database  consists  of  three  components: 
component  one  of  a  substrate,  a  challenge,  and  a  rights  certificate.  For  conciseness,  we  define 
product  types  for  these  composites  and  projection  functions  for  these  types. 

Substrates:  t.subs  —  t^subsx  X  tsubs2 

If  m  =  (t?2i,  7722)  has  type  tsubs ,  then 


{comp! (772)  =  772 1 ,  and 

COmp2(772)  =  7722. 


Account  database  entries:  Lacc  =  t.id  X  t.num  X  t^num 

(  id(7n)  =  772i, 

If  772  =  (7721 ,  tt22,  tt23)  has  type  t.acc ,  then 


accn(m)  =  ra2,  and 
[  osecret(m)  =  7723. 


109 


Deposit  database  entries:  t-deposit  —  Lsnbsi  x  t.cs  X  tjrcert 

subsComp  (m)  =  m1? 

If  m  =  m3)  has  type  ^deposit ,  then  ^  cs(m)  =  m2,  and 

rc(m)  =  m3. 


For  readability,  we  syntactically  distinguish  applications  of  cryptographic  functions  and  projec¬ 
tion  functions.  Applications  of  cryptographic  functions  are  denoted  in  a  standard  way:  f(a  i, . . an), 
where  /  is  the  function  and  a;,  i  —  1, . .  .,n,  are  the  arguments.  Applications  of  projection  func¬ 
tions,  on  the  other  hand,  are  denoted  as  a./,  where  a  is  the  argument  and  /  is  the  function.  For 
example,  if  m  is  a  substrate,  then  we  use  blind  (m,  b)  to  denote  the  result  of  blinding  m  with  6,  and 
m.subsi  to  denote  m’s  first  component. 


5.4  Formalizing  the  Protocol  and  the  Protection  Properties 

In  this  section,  we  specify  Brands’s  protocol  using  our  specification  formalism  (Section  2.3),  and 
give  concrete  specifications  of  protection  properties  as  applied  to  this  protocol. 

Different  participants  have  different  interests  to  preserve  in  different  ecash  transactions.  As  a 
result,  the  notion  of  protection  should  be  applied  to  withdrawal,  payment,  and  deposit  transactions 
separately.  This  enables  us  to  tackle  each  subprotocol  in  turn.  In  each  of  the  following  subsections, 
we  first  specify  the  subprotocol,  then  the  protection  properties  for  that  subprotocol. 

In  our  framework,  part  of  specifying  a  protocol  is  making  its  trust  assumptions  explicit.  For 
Brands’s  protocol  to  work,  both  B  and  O  need  to  be  trusted  in  different  ways.  Brands  does  not 
address  this  issue  uniformly.  In  [14],  he  explicitly  assumes  that  O  generates  and  erases  secrets 
as  prescribed;  however,  he  does  not  make  trust  assumptions  about  B  explicit.  Thus,  the  trust 
assumptions  that  appear  in  our  specification  of  the  protocol  are  results  of  our  inference,  rather 
than  transcriptions  of  what  appear  in  [14]. 

To  specify  the  protection  properties,  we  first  formulate  them  abstractly;  we  then  make  them 
concrete  for  Brands’s  protocol;  finally,  we  formalize  the  concrete  refinements.  Identifying  protection 
properties  for  each  of  ecash  subprotocols  has  turned  out  to  be  challenging.  While  there  have  been 
a  number  of  studies  [3,  42,  89]  on  fairness  (and  protection  properties  indirectly)  for  exchange 
protocols,  no  similar  studies  have  been  done  with  ecash  protocols. 

In  what  follows,  w,x,y,z  are  variables;  identifiers  in  Small  Cap  are  constants;  and  those  in 
slanted  fonts  are  placeholders  for  more  complex  messages. 


5.4.1  The  Withdrawal  Protocol 
Principals  of  the  Protocol 

P  =  {P,P,0} 
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Initial  Conditions 

Let  k^1  and  be  respectively  a  private  and  a  public  key;  ip  be  a  principal  id;  6P  and  0o  be  two 
numbers;  and  acp  be  an  account  database  entry.  The  initial  condition 

Xw  =  {k^\acp}  C  MSb  A  {ip,6p,T0,kh}  C  MSP  A  { 0O }  C  MS0  A 
shareable^1,  { B })  A  keyPair^1,  k &)  A 

shareable(acp,  {P})  A  acp. id  =  ip  A  ac^.accn  =  9p  A  acp. osecret  =  0O  A 
shareable(0p,  { jP})  A  shareable(0o,  {P,0}) 

says  that  1)  k^1  and  are  respectively  P’s  private  and  public  keys,  6p  is  P’s  account  secret, 
90  is  O’s  observer  secret,  ip  is  P’s  id,  and  acp  is  P’s  account;  2)  these  messages  are  held  by  the 
appropriate  principals;  and  3)  O  is  P’s  observer. 

Local  Protocols 

In  what  follows,  Secret- Request  denotes  a  predefined  message  used  by  P  to  request  O’ s  contri¬ 
bution  to  a  substrate. 

P’s  local  protocol  IZWp  consists  of  the  following  rules: 

RWbx  :  fix  :  t.subs  |  receive(P,  x)  G  H  =>  {receive(P,  y :  Lsu&s)} 

RWb2:  3a::  tsubs  |  last(H)  =  receive(P,  a:)  =>  {send(P,  seal  (a:,  acp.  accn,  ac^.osecret,  ft^"1))} 
RWbs-  3x  :  tseal  |  last(H)  =  send(P,  x)  =$>  {exit} 

P’s  local  protocol  IZWp  consists  of  the  following  rules: 

RWp^i  send(0,  Secret-Request)  £  H  =>  {send(0,  Secret-Request)} 

RWp2 :  fixi,x2,x3  :  t.num  |  x\  /  x2  A  a,q  x$  A  x2  x3  A 

random(aq)  G  H  A  random(a:2)  €  H  A  random (0:3)  G  H  =>  {random(y:  t.num)} 

RWp5:  send(0,  Secret- Request)  g  H  A  fix  :  t-num  |  receive(0,  x)  g  H  =>• 

{ receive (O,  y:  Lnum)} 

RWp6  :  3yi,  y2,  y3, s  :  t-num  \  y1  ^  y2  A  yx  /  y3  A  y2  7^  y3  A 

random(yi)  G  H  A  random(y2)  G  H  A  random(y3)  G  H  A  receive(0,  x)  G  H  A 
,3^:  Lsu&s  |  send(P,2)  G  H  =>  {send(P,  blind (compl  comp2,  y3))}, 

where  compl  =  subsi(0p,  yi,  0O)  and  comp2  =  subs2(yi,  y2, a:) 

PWp7:  3a::  tsubs  |  last(H)  =  send(P,a:)  =>  {receive(P,  y:  tseal)} 

RWps :  3a::  tseal  |  last(H)  =  receive(P,  a:)  =>  {exit} 

O’s  local  protocol  IZWo  consists  of  the  following  rules: 

RWox :  receive(P,  Secret-Request)  0  H  ==>  {receive(P,  Secret-Request)} 
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RWq2 :  last(H)  =  receive(P,  Secret- Request)  =>  {random (y:  t-num)} 

RWoz '  3x:  t-num  |  last(H)  =  random  (a;)  =>  {send(P,  x )} 

PIFoy  3x:  t-num  |  last(H)  =  send(P,  a:)  =>  {exit} 

Trust  Assumptions 

P  is  not  a  trusted  party;  thus,  Tpw  —  true.  B  and  O  are  both  trusted.  B  is  trusted: 

Tbw  •  To  generate  only  valid  signatures; 
and  O  is  trusted: 

Tow  :  To  provide  P,  as  its  contribution  towards  building  a  substrate,  with  a  number  for  which  it 
can  produce  protocertificates. 

These  trust  assumptions  can  be  formalized  as  follows: 

Tbw :  V#  :  tseal ,  m(send (P,  #)  E  HB  — > 

3y  :  tsubs  |  receive(P,  y)  €  HB  A  x  =  seal(y,  acp. accn,  acp. osecret,  A:-1)). 

Toy  V.t  :  t-num ,  □(send(P,  a:)  €  H°  — >  3y  :  t-num  \  y  E*  MS0  A  y  =  a:). 

TBw  says  that,  at  any  state  of  an  execution,  if  B  sends  P  a  signature,  then  the  signature  is 
correctly  generated.  The  correctness  condition,  expressed  by  x  =  seal(y,  acp.accn,  acyosecret,  A:-1) 
in  our  formalization,  says  that  a  signature  is  correctly  generated  if  it  embeds  the  right  substrate, 
the  right  private  key,  and  the  right  information  from  the  withdrawing  account.  Tow  says  that,  at 
any  state  of  an  execution,  if  O  sends  P  a  number  x,  then  it  must  be  a  one-way  function  of  a  number 
y  retrievable  from  O’ s  local  state.  Intuitively,  unless  this  condition  is  satisfied,  O  will  not  be  able  to 
provide  protocertificates  for  the  coin  being  withdrawn,  because  to  do  so,  O  needs  a  number  whose 
one-way  function  equals  the  number  it  gave  to  P  during  the  withdrawal  protocol. 

Protection  Properties 

Abstractly,  withdrawal  transactions  are  transactions  where  account  holders  withdraw  cash  from 
their  accounts.  A  withdrawal  transaction  is  correct  if  and  only  if  the  amount  of  cash  the  account 
holder  receives  equals  the  amount  deducted  from  his  or  her  account.  Two  protection  properties 
derive  from  this  correctness  condition.  For  the  account  holder,  his  or  her  total  amount  of  money 
should  not  decrease;  that  is,  the  amount  deducted  from  the  account  should  never  be  bigger  than 
the  amount  of  cash  he  or  she  receives.  For  the  bank,  the  account  holder  should  not  be  able  to  get 
cash  from  nowhere;  that  is,  the  amount  of  cash  the  account  holder  receives  should  never  be  bigger 
than  the  amount  deducted  from  the  account. 

In  the  abstract  properties  above,  the  word  cash  implies  something  that  is  spendable  and  that 
will  be  accepted  for  deposit  in  the  bank.  In  Brands’s  protocol,  spendability  of  a  coin  is  a  principal- 
dependent  notion:  a  principal  can  spend  a  coin  if  and  only  if  he  or  she  can  provide  rights  certificates 
for  it.  For  deposit,  coins  are  accepted  only  once:  a  coin  is  accepted  for  deposit  only  if  it  has  not  been 
deposited  before.  To  ensure  that  all  rightfully  withdrawn  coins  can  be  deposited,  Brands’s  protocol 
generates  only  coins  that  do  not  exist  anywhere  in  the  system  before.  We  call  them  newly-created 
coins. 
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Taking  into  account  the  mechanisms  just  described,  and  the  facts  that  only  one  coin  is  issued 
per  transaction  and  that  there  are  coins  of  only  one  denomination  (one  unit)  in  Brands’s  withdrawal 
protocol,  P’s  and  S’ s  protection  properties,  Pp  and  P% ,  can  be  respectively  refined  into 

“If  B  deducts  one  unit  from  P’s  account,  then  P  will  acquire  a  newly-created  coin  for 
which  she  can  provide  rights  certificates,” 


and 

“If  P  acquires  a  newly-created  coin  for  which  she  can  provide  rights  certificates,  then 
B  deducted  one  unit  from  P’s  account.” 

We  do  not  model  account  deduction  explicitly  in  Brands’s  protocol,  but  assume  that  B  has 
capabilities  for  transaction  processing,  and  will  deduct  one  unit  from  P’s  account  if  and  only  if  it 
issues  P  a  coin.  With  this  assumption,  Pfi  and  Pp  can  now  be  formalized  as 

P^  :  -)•  □($£  -4  <0$£), 

and 

□($£  -4  OSg), 

where 

<I>™  =  V.t  :  tsubs,  ( 3y  :  t.seal  |  vseal(a:,  y,  kb)  A  (y  €*  MSP  V  y  G*  MS8  V  y  €*  MSE))  <4  x  G*  12, 

=  3x  :  tseal  |  send(P,  a;)  €  HB, 

$P  =  3xi  :  tsubsi;x2  :  tsubs2-,xs  :  t-seal-,yi,y2,y3,z  :  t-num  \  fa  A  fa  A  fa , 

and 

fa  =  {*1,  X2,  £3}  C*  MSP  A  vsea\(x1x2,X3,kb), 

fa  =  £i£2  ft, 

fa  =  xi  =  subSl(^,yiA)  A  x2  =  subs2(yi,y2,0o,z)  A  z  =  1/3  A 
{0p,0o,yi,y2,zfa  C*  MSP  A  {<?„,  y3}  C*  MSP  U  MS0. 

defines  ft  as  the  set  of  substrates  for  which  P’s  signatures  exist.  We  use  ft  to  distinguish 
preexistent  coins  from  newly-created  ones:  if  a  coin’s  substrate  is  in  ft,  then  the  coin  is  preexistent; 
otherwise,  it  is  newly-created.  $jg  formalizes  “P  issued  P  a  coin”.  And  fa,  fa,  and  fa  respectively 
formalize  “P  owns  a  coin”,  “the  coin  is  newly-created”,  and  “P  jointly  with  O  can  provide  rights 
certificates  for  it” . 

5.4.2  The  Payment  Protocol 
Principals  of  the  Protocol 

V={P,0,E} 


113 


Initial  Conditions 

Let  0P,  0o,  v\p,  v2p,  and  v0  be  numbers;  u  be  a  substrate;  g  be  a  signature;  k^1  and  kb  be  respectively 
a  private  and  a  public  key;  ie  be  E' s  id;  F  be  the  set  of  challenge  seeds  E  has  used  before;  B  be 
the  bank;  and  A  be  B’s  deposit  database.  The  initial  condition 

lp  =  {u,g,0p,vlp,v2p,To,TE}  C*  MSP  A  {0o,  u0]  C*  MS0  A  {kb,  ie,  T}  C*  MSE  A  A  G*  MSB  A 
shareable^))"1,  {B})  A  keyPair(A;^1,  kb)  A 
u  =  {snbsi{6p,i/lp,6o),s\ibs2{i>ip,V2p,0o,TE))  A  vseal(«,y,  fcj)  A 
shareable(0p,  { P })  A  shareable(z/ip,  { P })  A  shareable)^,  {P})  A 
shareable^,,,  {B,  O})  A  shareable(z/0,  {O})  A 
Vx  :  t.cs,  chal(ie,  x)  G*  A  — >•  x  G  T 

says  that  k^1  and  kb  are  respectively  B’ s  private  and  public  keys;  P  has  a  valid  coin  ug  only  she 
jointly  with  O  can  spend;  and  T  actually  contains  all  stale  challenge  seeds.  Note  that  B  appears  in 
lp,  even  though  it  does  not  actively  participate  in  the  payment  protocol.  B  is  needed  in  lp  because 
the  validity  of  a  coin’s  signature  is  defined  in  terms  of  B’s  private  key. 

Local  Protocols 

In  the  specification  below,  we  need  two  types  of  events  not  listed  in  Def.  2.4  (Section  2.2.2): 
new(x,y)  and  delete(x).  We  use  new(a:,y)  to  model  the  generation  of  elements  y  not  found  in  the 
set  x.  In  the  context  of  Brands’s  payment  protocol,  new(T,  a)  models  the  generation  of  a  challenge 
seed  o,  different  from  all  those  that  E  has  used  before,  delete^)  is  used  to  model  the  deletion 
of  element  x  from  a  principal’s  message  set  MS.  This  type  of  event  is  needed  to  specify  O’ s  local 
protocol,  where  O  erases  coin-specific  secrets  va  after  they  have  been  used  towards  generating  a 
protocertificate. 

P’s  local  protocol  IZVp  consists  of  the  following  rules: 

RPp i :  fix  :  tsubs,  y  :  t.seal  |  send(B,  xy)  G  H  ==>  {send(B,  ug)} 

RPp2:  3.r  :  t.subs,y  :  t_seal  |  last(H)  =  send (E,xy)  ==>  {receive(B,  z  :  t.chal)} 

RPp3:  3.r  :  t^chal  |  last(H)  =  receive (E,  x )  =£•  {send(0,a:)} 

RPp4 :  3x  :  t-chal  |  last(H)  =  send(0,x)  =>  {receive(0,y  :  tzpcert )} 

RPps :  3.r  :  tjpcert,  y  :  t^chal  |  last(H)  =  receive(0,  x)  A  recei ve(E,y)  G  H  A 
vpcert {x,y,0o,TE)  =>  {send(B,  rcert(a:,  0P,  vXp,  i^p))} 

PPp6:  3x  :  t-pcert,y  :  t-chal,z  :  t-rcert  |  last(H)  =  send(B,  z)  V 

(last(H)  =  receive (O,  x)  A  receive(B,  y)  G  H  A  -wpcert (x ,  y ,T0,iE))  =>  {exit) 

O’s  local  protocol  IZVo  consists  of  the  following  rules: 

RP0i:  fix  :  t.chal  |  receive(P,x )  G  H  =>  {receive(P,  y  :  t-chal )} 

RPq2 :  3a:  :  t.chal  \  last(H)  =  receive(P,  .r)  A  v0  G*  MS0  =>  {send(P,  pcert(a;,  0o,  u0))} 
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RPo3:  3x\  :  t-pcert,x 2  :  <_n«m  |  last(H)  =  send(P,a:i)  A  X\  —  pcert(— ,  — ,  X2)  =>  {delete^)} 

RPo4:  (3 x:t  j num  |  last(H)  =  delete(a;))  V 

(3 y  :  t-.chal  |  last(P)  =  receive(P,  y)  A  v0  £  MS0)  =3-  {exit} 

P’s  local  protocol  7 ZVe  consists  of  the  following  rules: 

RPe4’  fix  :  tsubs  x  tseal  |  receive(P,  x)  G  H  {receive(P,  y  :  tsubs  x  tseal )} 

RPe2:  3x  :  tsubs  x  tseal  |  last(H)  =  receive(P,  a:)  {new(r,  y  :  Pcs)} 

RPes,'  V.r  :  tJd,  (x  =  ie  A  3y  :  t.cs  \  last(H)  =  new(r,  y))  =>  {send(P,  chal(a:,  y))} 

RPe4:  3x  :  t-chal  \  last(H)  =  send(P,  x)  =>  {receive(P,  y  :  tjrcert)} 

RPe3-  3a:  :  tjrcert  \  last(H)  =  receive(P,  x)  =»  {exit} 

Trust  Assumptions 

Neither  P  nor  E  is  trusted.  Thus,  Tp  =  true  and  Te  =  true.  O  is  trusted.  It  is  trusted: 

•  Top :  To  delete  v0  only  after  it  has  provided  P  with  a  protocertificate. 

Top  can  be  formalized  as  follows: 

Top :  □(delete^)  €  H°  (3a:i  :  t-chal,x 2  :  t.pcert  \ 

receive (P,  x\)  e  H°  A  send(P,  a:2)  €  H°  A  a:2  =  pcert(a:i,  0o,  v0)))- 

The  formalization  says  that,  at  any  state  of  an  execution,  if  O  deletes  v0,  then  it  must  have  sent  P 
a  correctly  generated  protocertificate  embedding  va. 

Protection  Properties 

Payment  transactions  are  transactions  where  money  is  given  from  one  party  to  another.  Abstractly, 
a  payer’s  interests  are  protected  if  his  or  her  money  does  not  disappear,  that  is,  if  what  he  or  she 
gives  up  is  actually  received  by  the  payee.  A  payee’s  interests  are  protected,  on  the  other  hand,  if 
what  he  or  she  receives  is  or  will  eventually  be  worth  money. 

In  Brands’s  protocol,  payments  are  made  with  coins.  However,  when  P  pays  E,  she  does  not 
give  up  a  coin;  she  can  always  keep  a  copy  of  the  coin  around.  Instead,  she  gives  up  her  rights  to 
the  coin.  Concretely,  P  makes  payments  by  providing  rights  certificates  for  the  coins  being  paid; 
and  the  generation  of  a  rights  certificate  for  a  coin  makes  her  lose  her  ability  to  generate  other 
rights  certificates  for  the  same  coin. 

A  coin  and  its  accompanying  rights  certificate  is  or  will  eventually  be  worth  money  if  the  coin 
can  be  deposited  in  the  bank  or  if  the  identity  of  the  payer  can  be  revealed  -  thus  enabling  E  to 
go  after  P  and  claim  the  amount  due  off-line.  A  coin  can  be  deposited  if  it  has  not  been  before, 
and  the  rights  certificate  gives  rights  to  the  depositor.  The  identity  of  the  payer  can  be  revealed  if 
the  coin  has  been  deposited,  but  the  rights  certificate  recorded  in  the  deposit  database  (presented 
when  the  coin  was  accepted  for  deposit)  differs  from  the  one  being  presented. 

Tailored  to  Brands’s  protocol,  P’s  and  P’s  protection  properties,  Pp  and  PI  can  now  be 
informally  stated  as 
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“If  P  loses  her  ability  to  provide  rights  certificates  for  a  coin,  E  will  receive  the  rights 
to  this  coin”, 


and 


“If  E  receives  a  coin  and  an  accompanying  rights  certificate  provided  in  response  to  his 
challenge,  then  E  can  deposit  the  coin  or  can  have  P’s  identity  revealed.” 


Pp  and  Pp  can  now  be  formalized  as: 

Pp  :  \/xi  :  t-subsi'X2  :  tsubs2;z  :  tseal ;  t/i, . . . ,  y5,  wi,  W2  :  t.num, 

($:  -4  □(*£  ->  oirE ,)) 

and 


P&  :  Vxj  :  tsubs ;  x<i  :  tseal ;  :  tjrcert ;  x4  :  t.chal ,  D($^2  3>-g), 

where 

=  {yi,...,y5,^}  C*  MSP  A  {«7i,u>2}  C*  MSp  UMS°  a  uJT  =  y4  A  =  y5  A 

a-'i  =  subsi  (yT,  2/2 >  2/4)  A  a;2  =  subs2(t/2, 2^3,  J/4, 2/5)  A  vseai(x1x2,  z,  kb), 

$PP  =  w2  $.*  MSP  UMS°, 

$Ei  =  :  t-rcert,z2  :  Pcs  |  receive(P,  arjar2«)  £  HE  A  receive(P,  G  HE  A 

22  G*  MSe  A  vrcert(zi,chal(ie,22),zi*2)) 

$E2  =  receive(P,  £1*2)  £  HE  A  vseal(a;i,  x2,  h)  A  send(P,  *4)  G  HE  A 
receive(P,  a:3)  G  He  A  vrcert(a:3,  x4,  xi), 

=  x4  =  chal(«e,  — )  A  (.'Ci.compj  g*  A  V  £3  A). 

formalizes  “P  jointly  with  O  can  spend  a  coin”;  4>p  formalizes  “P  loses  the  ability  to  spend 
the  coin” ;  $pEl  formalizes  UE  receives  the  rights  to  the  coin” ;  &PE2  formalizes  E  receives  a  coin  and 
an  accompanying  rights  certificate  provided  in  response  to  his  challenge;  finally,  <f>#  formalizes  “E 
was  given  the  rights  to  the  coin”  and  “not  both  the  coin  and  the  rights  certificate  can  be  found  in 
the  deposit  database”. 

Note  that  Pp  and  PE  differ  from  all  protection  properties  we  have  seen  so  far  in  this  dissertation. 
While  protection  is  about  getting  a  fair  return  for  what  one  gives  up  or  is  taken  away  from  in  all 
previous  protection  properties,  it  is  about  preservation  of  a  value  in  Pp,  and  validity  of  what  one 
receives  in  PE- 

5.4.3  The  Deposit  Protocol 
Principals  of  the  Protocol 

V={E,B} 
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Initial  Conditions 

Let  u,  g,  and  r  be  respectively  a  substrate,  a  signature,  and  a  rights  certificate;  ie  be  B’ s  id;  t  be  a 
challenge  seed;  and  kb  be  respectively  a  private  and  a  public  key;  ace  and  acP  be  two  entries 
in  P’s  account  database;  A  be  P’s  deposit  database;  0P  and  60  be  numbers;  and  P  be  the  payer. 
The  initial  condition 

Id  =  {u,g,r,  ie,  t)  C*  MSE  A  {k^1 ,  kb,  ace,  acp,  A}  C*  MSB  A 
shareable^1,  {P})  A  keyPair(fy}x,  kb)  A 
shareable(0p,  {P})  A  o.cp. accn  =  6p  A  acp. osecret  =  0o  A 
u  =  (subsi(0p,  — ,  0O),  subs2(— ,  — ,  60,  — ))  A 
vseal(u,0,  kb)  A  ace .id  =  ie  A  vrcert(r,  chal(ie,  t),  u) 

says  that  k^1  and  kb  are  respectively  P’s  private  and  public  keys,  ace  and  acp  are  respectively  E 
and  P’s  accounts;  P’s  account  secret  is  known  to  no  one  other  than  P;  and  E  has  a  valid  coin  (ug) 
withdrawn  from  P’s  account  and  a  rights  certificate  (r)  giving  him  rights  to  the  coin.  Note  that  P 
appears  in  ld ,  even  though  she  does  not  actively  participate  in  the  deposit  protocol.  P  is  needed 
in  ld  to  specify  the  value  of  the  account  secret  6P  embedded  in  the  coin. 

Local  Protocols 

In  the  specification  below,  we  need  one  type  of  event  not  listed  in  Def.  2.4  (Section  2.2.2):  credit(x). 
Credit(a:)  models  P’s  crediting  account  x. 

P’s  local  protocol  TZT>e  consists  of  the  following  rules: 

RDex  :  Jdx\  :  t.subs,x2  :  t.seal,x3  :  t.cs,  x4  :  t.rcert  \  send(B,  a^a^a^a^)  £  H  =£-  {send (B,ugtr)} 
RDe2 :  3*i  :  t.subs,x2  :  t.seal,x3  :  t.cs,x 4  :  t.rcert  |  last(H)  =  send  (B,  3:13:2*3*4)  =>  {exit} 

P’s  local  protocol  1ZT>b  consists  of  the  following  rules: 

PPb,:  flx\  :  t.subs,x2  :  t.seal,x3  :  t.cs,x 4  :  t.rcert  |  receive(E, 3:10:2*3*4)  €  H  => 

{receive(B,  x^x^x^x'^)} , 

where  x[:  t.subs,  x'2:  t.seal ,  3:3:  t.cs ,  and  x'4:  t.rcert 
RDb2'  Va;  :  t.acc,  x  =  ie  A 

(3a:  1  :  t.subs,x2  :  t.seal,x3  :  t.cs,x 4  :  t.rcert  |  last(H)  =  receive(P,  0:13:2*3*4)  A 

vseal(a:i,3:2,  h)  A  vrcert(a;4,  chal(*e,  a:3),  x\)  A 

^3:5  :  t. deposit  £  A  |  a:5.subsComp  =  a:i.compi)  =£>  {credit(a:)} 

RDb3 :  3*i  :  t.subs,x2  :  t.seal,  x3  :  Pcs,  a: 4  :  t.rcert  |  (last(H)  =  receive(P,  xix2xsx4)  A 
(~ivsea\(xi,x2,kb)  V  -.vrcert(x4,  chal(ace.id,  x3),  3:1)  V 
33:5  :  t. deposit  £  A  |  a^.subsComp  =  a:i.compi))  V 
last(H)  =  credit(ace)  =>■  {exit} 
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Trust  Assumptions 

E  is  not  trusted.  Thus,  7#  =  true.  B  is  trusted.  It  is  trusted: 

•  Tgd:  To  deposit  not-yet-deposited  valid  coins  into  the  accounts  of  depositors  who  have  rights 
to  them. 

Tsd  can  be  formalized  as  follows: 

Tb d:  V#i  :  tsubs,x2  :  tseal,x 3  :  t.cs,x4  :  i-vceri , 

□  (last(HB)  =  receive(P,  x\ . .  .x4)  A  vseal(a?i,  x2,  h)  A  vrcert(x4,  cha,l(ace.id,  £3),  xi)  A 
fix 5  :  t .deposit  G  A  |  Xs.subsComp  =  a;i.comp1  — *  O  credit(ace)). 

The  formalization  says  that,  at  any  state  of  an  execution,  if  B  receives  a  not-yet-deposited 
valid  coin  and  a  rights  certificate  giving  the  depositor  the  rights  to  the  coin,  then  B  will  credit  the 
depositor’s  account. 

Protection  Properties 

Deposit  transactions  are  transactions  where  cash  is  put  in  a  banking  account.  Physical  world 
deposit  transactions  are  correct  if  and  only  if  the  amount  of  cash  given  up  by  the  depositor  equals 
the  increase  in  the  depositor’s  account  balance. 

To  emulate  physical  deposit  transactions  in  the  electronic  realm,  Brands’s  protocol  uses  aux¬ 
iliary  measures.  For  example,  to  avoid  accepting  a  coin  for  deposit  a  second  time,  banks  keep  a 
record  of  coins  that  have  been  deposited.  To  prevent  thieves  from  depositing  stolen  coins,  rights 
certificates  are  required  in  deposit  transactions. 

Taking  into  account  these  auxiliary  measures,  P’ s  and  P’s  protection  properties,  Pg  and  P|, 
can  be  informally  stated  as: 

“If  B  accepts  a  coin  for  deposit,  then  the  coin  is  valid  and  has  not  been  deposited 
before,” 


and 


“When  E  submits  for  deposit  a  valid  coin  c  and  a  rights  certificate  giving  him  the  rights 
to  c  -  for  the  first  time,  either  c  will  be  deposited  into  P’s  account  or  P’s  identity  will 
be  revealed,” 

respectively. 

Pg  and  Pg  can  now  be  formalized  as: 

Pg  :  Va?!  :  t.subs ,  x2  :  tseal ,  □($g1  — >  $g2)> 

Pg  :  V.Ti  :  tsubs ,  x2  :  t.seal ,  xs  :  Pcs,  x4  :  tjrcert ,  □($#3  O $g), 
where 

$Bi  —  receive(P,  X\X2 - )  G  HB  A  credit(-)  G  HB, 

<3>g2  —  vseal(»i,£2,  h)  A  ^i.compj  A, 
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=  receive(.E,  Zia^s^)  €  HB  A  vseal(aii,  *2,  kf)  A 
vrcert(a-4,  chal(ace.id,  x3),  2:1)  A  x4  A, 

$£»  =  credit(ace)  €  HB  V  6P  G*  MSB. 

*£1  formalizes  “5  accepts  the  coin  x  1 .7*2  for  deposit”;  4>jg2  formalizes  ux  1  x 2  is  a  valid  coin  that 
has  not  been  deposited”;  $dB3  formalizes  “ B  receives  a  valid  coin  and  a  not-yet-submitted  rights 
certificate  giving  E  the  rights  to  the  coin”;  finally,  <&dE  formalizes  “E’s  account  is  credited  or  P’s 
identity  is  revealed”. 

Note  that  our  formalization  captures  the  fact  that  all  B  cares  about  is  depositing  valid  coins 
that  have  not  been  deposited  before.  Depositing  stolen  coins  does  not  really  hurt  F’s  interests;  it 
hurts  E' s  interests  instead.  Also  if  B  does  not  accept  the  coin  for  deposit,  then  P’s  identity  should 
be  revealed,  so  that  E  can  go  after  P  and  claim  the  amount  due  off-line. 


5.5  Analysis  of  the  Protocol:  Preliminaries 

In  the  rest  of  this  chapter,  we  analyze  Brands’s  protocol  with  respect  to  protection  of  individuals’ 
interests.  As  our  specification  (Section  5.4)  of  transaction-specific  protection  properties  may  have 
forecasted,  we  do  not  analyze  the  protocol  as  a  whole.  Instead,  we  see  it  as  consisting  of  three 
subprotocols,  and  analyze  each  of  them  separately.  Each  subprotocol  is  analyzed  under  all  three 
deviation  modes  defined  in  Chapter  2.  In  Section  5.6,  Subsections  5.6.1,  5.6.2,  and  5.6.3  have 
analyses  of  the  withdrawal  protocol  under  deception,  compliance,  and  abortion  modes,  respectively; 
Subsection  5.6.4  has  summary  and  conclusions.  Sections  5.7  and  5.8,  with  parallel  structures  to 
Section  5.6,  concern  the  payment  protocol  and  the  deposit  protocol  respectively. 

To  analyze  Brands’s  protocol,  we  repeat  the  proof  strategy  we  used  for  NetBill.  That  is,  we 
first  prove  that  trustworthy  executions  satisfy  our  target  properties;  and  then  argue  that  maximal 
compliant  executions  also  do,  because  they  are  trustworthy. 

In  what  follows,  we  present  results  needed  in  the  following  three  sections.  Lemmas  3.2  says 
that,  in  Brands’s  protocol,  each  protocol  step  gets  instantiated  at  most  a  finite  number  of  times 
in  executions  we  consider.  Its  proof  is  straightforward,  and  depends  on  the  fact  that  the  protocol 
rules  either  have  enabling  conditions  that  prevent  the  same  types  of  events  from  occurring  more 
than  n  ( n  finite)  times,  or  can  be  enabled  only  once,  by  an  occurrence  of  an  event  that  cannot 
occur  more  than  once. 

Lemma  5.2  Let  II  be  withdrawal  (payment,  or  deposit)  protocol,  a  be  an  execution  in  E(U)C  U 
F(II)^  U  E(Yl)D,  e,-  be  an  event  in  a,  and  E  be  an  event-template  prescribing  a  protocol  step  in 
II.  If  e,  is  an  instance  of  E,  then  there  exist  only  finite  number  of  different  ej, ,  ey2 , . . . ,  ejn  in  a, 
i  jkt  k  =  1, ...  ,7i  such  that  ejk  is  also  an  instance  of  E. 

Theorems  5.3,  5.4,  and  5.5  say  respectively  that  all  maximal  compliant  executions  of  Brands’s 
withdrawal,  payment  and  deposit  protocols  are  trustworthy. 

Theorem  5.3  Let  II  be  Brands’s  withdrawal  protocol  and  T  =  TBw  AT0,„  be  its  trust  assumptions. 
Then 

Vct  G  E{ n)c,  a  K  T. 
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Proof:  Straightforwardly,  from  rules  RWb2  and  RWos. 


Theorem  5.4  Let  II  be  Brands’s  payment  protocol  and  T  =  Top  be  its  trust  assumptions.  Then 

Vd  e  E(U)C ,  a  |=*  T. 


Proof: 

1.  Let  S{  be  a.  state  in  a  such  that  S{  [=  delete^)  £  H°. 

delete(^0)  must  have  resulted  from  an  application  of  rule  RPo3-  Therefore,  there  must  be  a 
state  Sj,  j  <  i ,  and  a  protocertificate  m  such  that  Sj  (=  last(H°)  =  send(m). 

2.  Send(m)  must  have  resulted  from  an  application  of  RPo2.  Therefore,  there  must  be  a  state  sk, 
k  <  j i  and  a  challenge  m'  such  that  sk  J=  last(H°)  =  receive(P,  rn')  and  m  =  pcert(m',  0o ,  i/0). 

□ 


Theorem  5.5  Let  II  be  Brands’s  deposit  protocol  and  7  =  Tsd  be  its  trust  assumptions.  Then 

V(7  6  E(U)C,  a\ =*T. 

Proof:  Straightforwardly,  from  rule  RDb2- 


□ 

In  the  rest  of  this  analysis,  we  assume  that  the  communication  channels  between  P  and  O  are 
reliable,  even  though  communication  channels  are  generally  unreliable  in  our  model.  We  make  this 
assumption  because  O  is  likely  to  stay  physically  close  to  P,  and  the  link  between  them  is  not  as 
likely  to  go  down. 

5.6  Analysis  of  the  Withdrawal  Protocol 

5.6.1  Protection  under  Deception  Mode 

In  this  subsection,  we  analyze  the  protocol  under  deception  mode.  We  first  analyze  it  with  respect 
to  P-protection,  then  with  respect  to  B-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  if  II  is  Brands’s  withdrawal  protocol,  then  to 
analyze  it  with  respect  to  P-protection  under  deception  mode,  we  need  to  analyze  all  executions 
in  P(n)c  and  trustworthy  executions  in  P(II)p.  We  do  so  in  Prop.  5.7  and  5.6  respectively. 

Proposition  5.6  Let  II  be  Brands’s  withdrawal  protocol,  a  be  an  execution  in  P(Il)p .  T  be  the 
trust  assumptions  II  makes,  and  Pp  =  — >•  □($#  — >  0$p)  be  P’s  protection  property  as  specified 

in  Section  5.4-1  (p.  112).  Then 

a  f=*  T  implies  o  |=*  Pp. 
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Analysis:  Let  a  =  So  e\  si  . . .  be  a  trustworthy  execution,  So  be  such  that  so  (=  ,  and  Si  be  a 

state  in  a  such  that  S{  \=  $£.  The  following  shows  that  there  exists  j,  j  >  i,  such  that  Sj  \=  4>p,  if 
we  assume  that  communication  channels  are  reliable  in  the  system. 

1.  If  Si  then  there  exists  a  signature  m  such  that 

S{  |=  send(P,  m)  £  HB.  (5.1) 

From  expression  5.1,  we  can  reach  two  conclusions.  First,  assuming  reliability  of  communi¬ 
cation  channels,  we  conclude  that  there  exists  j,  j  >  i,  such  that 

Sj  )=  receive(jB,  m)  £  Hp.  (5.2) 

Second,  according  to  the  trust  assumption  Tbw,  there  exists  a  substrate  m'  such  that 

Si  \=  receive  (P,  m')  £  H®  A  m  =  sea^m',  acp. accn,  acy. osecret,  k^1).  (5.3) 


2.  A  message  needs  to  be  sent  before  it  can  be  received.  Thus,  from  expression  5.3  (step  1),  we 
can  conclude  that 

Si  |=  send(P,  m!)  £  Hp, 

where  sendp(J9,  rn')  must  have  resulted  from  an  application  of  RWp&. 

3.  Next,  let  s,/,  i'  <  i,  be  the  state  at  which  RWp6  was  applied.  Then  there  exist  three  different 
numbers  nj,  n2,  and  n  such  that 

Sj/  |=  random(ni)  £  Hp  A  random(ra2)  G  Hp  A  random(n)  £  Hp, 


and  a  fourth  number,  n',  such  that 


4. 


and  m'  is  such  that 


S{i  |=  receive  (0,  n')  £  Hp, 


m!  =  blind(mjm2,  n), 

where  m\  =  subsx(0p,  0O)  and  m2  =  subs2(ni,  n2,  90,  n'). 
From  expression  5.4  (step  3),  we  can  conclude  that 

Sy  \=  send(P,  n  )  £  H°. 


(5.4) 


And  by  trust  assumption  Tow,  we  know  that  there  must  be  a  number  nz  such  that 

Si1  |=  ^3  €*  MS®  A  n'  =  nz- 


5.  We  can  now  prove  that 

Sj  \=  <f>i[mi/xi,m2/x2,unb\md(m,n)/x3]. 

(a)  From  expression  5.2  (step  1),  and  the  fact  that  So  |=  {0P,  0O}  C*  MSP,  we  know  that 

Sj  |=  {mi,  m2,  unblind(m,  n)}  C*  MSP. 
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(b)  And  vseal(mim2,  unblind (m,  n),  k &)  can  be  proven  straightforwardly  using  the  conver¬ 
sion  rules  in  Def.  5.1  (Section  5.3). 

6.  We  can  also  prove  that 

Sj  <f>2[m1/xumi/x2], 
since  m\  and  m2  have  submessages  generated  at  random. 

7.  Finally,  we  can  prove  that 

Sj  |=  foa, 

where  a  =  [mi/xu  m2/x2,  unblind(m,  n)/x3,  ni/yu  n2/y2,  n3/y3,  n'/z], 

(a)  From  the  initial  condition  1  and  step  3,  we  have 


Sj  H  Oo,  nli  n2i  n  }  C  MSP; 

(b)  Also  from  the  initial  condition  1  and  step  4,  we  have 

sj  |=  {0o,  n3}  C*  MS0. 

Note,  however,  that  communication  channels  are  not  reliable  in  our  model.  Thus,  4>\  may  never 
be  satisfied  because  P  may  never  receive  the  signature  from  B. 

□ 

Bearing  in  mind  what  and  specify  (Section  5.4.1),  the  analysis  of  Prop.  5.6  shows 

that  if  B  issues  P  a  signature,  consequently  deducting  one  unit  from  P’s  account,  and  the  com¬ 
munication  channel  between  B  and  P  does  not  fail,  then  P  will  acquire  a  newly-created  coin  for 
which  she  can  provide  rights  certificates. 

For  P  to  acquire  such  a  coin,  both  B  and  O  need  to  be  trustworthy.  If  B  does  not  behave  as 
specified  by  the  trust  assumption  Tbw,  and  generates  a  signature  that  embeds  numbers  other  than 
those  specified,  the  signature  it  returns  to  P  will  not  be  valid,  and  P  will  not  have  received  a.  coin. 
If  O  does  not  behave  as  specified  by  Tow  and  returns  a  number  from  which  it  cannot  generate 
an  appropriate  protocertificate  later  in  the  payment  protocol,  then  P  will  not  be  able  to  generate 
rights  certificates  for  the  coin.  Any  number  that  is  not  one-way  function  of  a  second  number  O 
possesses  will  lead  to  such  an  outcome. 

Finally,  reliability  of  the  communication  channel  between  B  and  P  is  critical  because  P  will 
have  a  coin  only  if  she  receives  the  signature  from  B.  If  the  link  between  B  and  P  goes  down  and 
the  signature  gets  lost  in  the  transmission,  P  will  have  her  account  deducted  without  receiving  a 
coin  in  return. 

Prop.  5.7  concerns  maximal  compliant  executions.  These  executions  are  trustworthy  and  have 
compliant  local  executions  of  P.  Given  that  our  analysis  of  Prop.  5.6  relies  on  the  fact  that  a  is 
trustworthy  and  has  a  compliant  local  execution  of  P,  it  can  be  used  as  is  to  analyze  Prop.  5.7. 

Proposition  5.7  Let  IT  be  Brands’s  withdrawal  protocol,  o  be  an  execution  in  E[YT)C ,  and  Pfi  be 
P’s  protection  property  as  specified  in  Section  5-4.1  (p.  112).  Then 

<7  |=*  Pfi. 
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From  Prop.  5.6  and  5.7,  we  can  derive  the  following 

Corollary  5.8  Brands’s  withdrawal  protocol  is  P -protective  under  deception  mode,  if  the  commu¬ 
nication  channel  between  B  and  P  is  reliable. 

Next  we  address  P- protection.  Like  in  the  analysis  of  P-protection,  we  analyze  deceptive  and 
compliant  executions  in  turn. 

Proposition  5.9  Let  II  be  Brands’s  withdrawal  protocol,  a  be  an  execution  in  and 

P^  =  4>’r  — >  □  i'4>p  -4  03>jg)  be  B’s  protection  property  as  specified  in  Section  5.4-1  (p-  112).  Then 

a  [=*  P%. 

Proof:  Let  s0  be  such  that  s0  |=  ,  and  Si  be  a  state  in  o  such  that  s;  (=  The  following 

shows  that  there  exists  j,  j  >  i,  such  that  Sj  )=  $£. 

1.  If  Si  \=  then  there  exists  a  substrate  mim2  and  a  signature  m3  such  that 

Si  \=  mim2  £*  Q  A  to3)  C*  MSP  A  vseal(mim2,  m3,  kf)  (5.5) 

2.  From  the  first  conjunct  in  expression  5.5  (step  1),  we  know  that 

sQ\=flx  :  tseal  \  x  G*  MSP  A  vseal(mim2,  x,  kb), 

which  means  that  to3  must  have  been  generated  or  received  by  P  during  the  current  protocol 
execution. 

3.  From  the  last  conjunct  in  expression  5.5  (step  1),  we  know  that 

m3  =  seal(mim2,  -,k^). 

Since  kf1  is  kept  private  to  B  at  all  times,  we  can  conclude  that  m3  could  not  have  been 
generated  by  P,  but  must  have  been  received  from  B.  And  according  to  P’s  protocol,  this 
message  is  a  signature.  Thus,  we  conclude  that  there  is  a  signature  m,  such  that 

Si  |=  receive(P,  to)  €  Hp.  (5.6) 

4.  Finally,  from  expression  5.6  (step  3),  we  can  conclude  that 

Si  |=  send  (P,  to)  €  HB. 


□ 

Bearing  in  mind  what  and  specify  (Section  5.4.1),  the  proof  of  Prop.  5.9  shows 

that  if  P  acquires  a  newly-created  coin,  B  must  have  issued  it.  This  is  so  because,  to  acquire  a 
newly-created  coin,  P  needs  a  newly-generated  signature,  which  can  be  provided  only  by  B.  Note 
that  P-protection  depends  on  neither  trust  assumptions  nor  reliability  of  communication  channels. 

Prop.  5.10  concerns  maximal  compliant  executions.  Our  proof  of  Prop.  5.9  is  readily  applicable 
here  because  it  only  relies  on  the  fact  that  o  has  compliant  local  executions  of  P,  a  condition 
satisfied  by  maximal  compliant  executions. 
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Proposition  5.10  Let  II  be  Brands’s  withdrawal  protocol,  a  be  an  execution  in  E(Y[)C ,  and  PJ' 
be  B’s  protection  property  as  specified  in  Section  5. 4-1  (p.  112).  Then 

o  b*  P%. 

From  Prop.  5.9  and  5.10,  we  can  derive  the  following 
Corollary  5.11  Brands’s  withdrawal  protocol  is  B-protective  under  deception  mode. 

Theorem  5.12  summarizes  the  results  in  this  subsection: 

Theorem  5.12  Brands’s  withdrawal  protocol  is  all-protective  under  deception  mode,  if  the  com¬ 
munication  channel  between  B  and  P  is  reliable. 

Proof:  From  Cor.  5.8  and  5.11. 


□ 


Discussion 

According  to  our  analysis,  P’s  interests  are  protected  under  deception  mode  only  if  the  commu¬ 
nication  channel  between  B  and  P  is  reliable.  Clearly,  if  the  channel  is  unreliable,  and  the  link 
goes  down  after  B  sends  P  the  signature,  but  before  P  gets  it,  then  B  will  have  deducted  from  P’s 
account,  but  P  will  not  have  received  a  coin. 

The  dependency  on  reliable  communication  channels  to  guarantee  P-protection  is  a  weakness 
of  this  protocol.  There  are  ways  of  bypassing  this  weakness  however.  For  example,  if  B  keeps 
a  database  of  blinded  substrates  for  which  it  has  issued  a  signature,  then  P  can  re-submit  a 
substrate  if  she  does  not  receive  the  signature  from  B.  B  issues  signatures  for  all  requests,  but 
only  debiting  the  requester’s  account  when  the  substrate  cannot  be  found  in  the  database.  Note 
that  B  does  not  need  to  keep  these  substrates  forever.  P  can  send  B  an  acknowledgment  when  she 
gets  the  signature,  and  B  can  delete  the  corresponding  entry  in  the  database  upon  receiving  the 
acknowledgment. 

Protection  of  P’s  interests  also  depends  on  B  and  O  satisfying  Tqw  and  Tow.  The  discussion 
following  the  analysis  of  Prop.  5.6  gives  an  intuition  of  how  the  violation  of  these  trust  assumptions 
can  compromise  P-protection. 

It  is  reasonable  to  assume  that  B  will  behave  as  trusted;  after  all,  it  is  P’s  interest  to  preserve 
long  term  relationships  with  its  clients.  There  is  an  alternative,  however,  if  B  cannot  be  trusted 
for  some  reason:  The  alternative  consists  of  making  receipt  of  messages  non-repudiable  [89].  With 
non-repudiation  and  P’s  ability  to  verify  a  signature’s  validity,  P  can  show  to  a.  third  party  that  P 
did  not  issue  a.  valid  signature  for  the  substrate  she  had  sent  and  can  therefore  demand  a  refund. 

Tow  is  a  more  critical  assumption,  and  relies  on  correct  implementations  of  smartcards.  Unlike 
with  P,  it  is  impossible  for  P  to  tell  whether  O  has  behaved  as  trusted  during  a  withdrawal 
transaction.  O’ s  misbehaving  can  be  detected  only  later,  when  P  tries  to  spend  the  coin,  and  finds 
out  that  O  is  unable  to  provide  appropriate  protocertificates.  One  possible  safeguard  against  O’s 
misbehavior  is  to  have  P  keep  a  record  of  the  signatures  it  issued  with  their  respective  requesters. 
When  P  finds  out  that  she  is  unable  to  spend  a  coin  because  of  O,  she  can  then  go  to  P  to  revoke 
the  corresponding  coin  and  get  a  refund. 
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Next,  we  focus  on  B-protection.  According  to  our  analysis,  B’s  interests  are  protected  under 
deception  mode,  independent  of  link  reliability  and  trust  assumptions.  This  is  not  surprising 
because  the  signature  of  a  newly-created  coin  can  be  generated  only  in  the  current  run  of  the 
protocol,  and  B  is  the  only  one  able  to  generate  it.  Thus,  if  P  acquires  a  newly-created  coin,  B 
must  have  provided  the  signature,  and  consequently  deducted  from  P’s  account. 

Note  that  both  P  and  O  can  deceive.  But  their  deceptions  do  not  violate  B’s  interests.  P’s 
deceptions  can  compromise  P’s  own  interests  however.  For  example,  if  P  embeds  something  other 
than  the  number  returned  by  O  in  the  substrate,  P  compromises  O’s  ability  to  provide  appropriate 
protocertificates  later  in  payment  transactions,  and  makes  the  coin  non-spendable.  Most  surpris¬ 
ingly,  however,  P’s  deceptions  can  compromise  B’s  interests  in  deposit  transactions.  We  will  show 
how  later  in  Section  5.8. 

All  in  all,  P  is  much  more  vulnerable  than  B  in  withdrawal  transactions.  While  P  needs  to 
rely  on  B  and  O’s  trusted  behaviors  and  reliability  of  communication  channels,  B  needs  to  rely  on 
only  the  cryptographic  strength  of  the  signature  scheme. 

5.6.2  Protection  under  Compliance  Mode 

In  this  subsection,  we  analyze  the  protocol  under  compliance  mode.  To  verify  whether  the  protocol 
is  all-protective  under  compliance  mode,  we  need  to  verify  whether  both  P’s  and  B’s  interests 
are  protected  in  maximal  compliant  executions.  But  these  results  have  already  been  verified  in 
Subsection  5.6.1.  According  to  Prop  5.7  and  5.10, 

Theorem  5.13  Brands  ’s  withdrawal  protocol  is  all-protective  under  compliance  mode,  if  the  com¬ 
munication  channels  between  P  and  B  are  reliable. 

Discussion 

Brands’s  withdrawal  protocol  is  not  all-protective  under  compliance  mode.  Like  under  deception 
mode,  it  is  B-protective,  but  not  P-protective.  It  is  B-protective  because  B  depends  on  nothing 
other  than  the  strength  of  the  signature  scheme  to  protect  its  interests.  It  is  not  P-protective 
because  P  still  risks  not  receiving  the  signature  from  B  due  to  unreliable  communication  channels. 

5.6.3  Protection  under  Abortion  Mode 

In  this  subsection,  we  analyze  the  protocol  under  abortion  mode.  Like  in  the  two  previous  subsec¬ 
tions,  we  need  to  verify  whether  the  protocol  is  both  P-protective  and  B-protective.  We  start  with 
P-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  to  verify  whether  II  protects  P’s  interests 
under  abortion  mode,  we  need  to  examine  all  executions  in  B(II)C  and  trustworthy  executions  in 
B(II)p.  Here  we  focus  on  abortive  executions  only,  since  we  have  analyzed  compliant  executions 
(Prop.  5.7)  in  Section  5.6.1. 

Proposition  5.14  Let  II  be  Brands’s  withdrawal  protocol,  o  be  an  execution  in  P ( 14 ) f, .  T  be  the 
trust  assumptions  U  makes,  and  Pp  be  P’s  protection  property  as  specified  in  Section  5.4-1  (p.  112). 
Then 

a  \=*  T  implies  o  )=*  Pp. 
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Prop.  5.14  can  be  analyzed  using  the  proof  for  Prop.  5.6.  That  proof  is  applicable  here  because 
it  relies  only  on  the  fact  that  executions  it  considers  are  trustworthy  and  have  compliant  local 
executions  of  P,  both  of  which  are  satisfied  by  executions  we  consider  under  Prop.  5.14.  A  critical 
condition  satisfied  by  the  proof  is  that  it  does  not  depend  on  P  or  O  taking  further  steps,  a 
requirement  that  could  be  violated  by  abortive  executions. 

From  Prop.  5.7  (Section  5.6.1)  and  5.14,  which  jointly  address  P- protection  under  abortion 
mode,  we  derive  the  following 

Corollary  5.15  Brands  's  withdrawal  protocol  is  P -protective  under  abortion  mode ,  if  the  commu¬ 
nication  channels  between  P  and  B  are  reliable. 

Prop.  5.16  addresses  protection  of  P’s  interests  in  abortive  executions  and  can  be  proven  using 
the  proof  for  Prop.  5.9  (Subsection  5.6.1).  That  proof  is  applicable  here  for  a  reason  analogous  to 
the  one  given  for  Prop.  5.14. 

Proposition  5.16  Let  II  be  Brands's  withdrawal  protocol \  a  be  an  execution  in  E(U)q,  and  Pg 
be  B's  protection  property  as  specified  in  Section  5.4-1  (p-  112).  Then 

v  K  Pb> 

From  Prop.  5.10  (Section  5.6.1)  and  5.16,  which  jointly  address  P-protection  under  abortion 
mode,  we  derive  the  following 

Corollary  5.17  Brands  's  withdrawal  protocol  is  B-protective  under  abortion  mode. 

Theorem  5.18  summarizes  the  results  in  this  subsection. 

Theorem  5.18  Brands  's  withdrawal  protocol  is  all-protective  under  abortion  mode ,  if  the  commu¬ 
nication  channels  between  P  and  B  are  reliable. 

Proof:  From  Cor.  5.15  and  5.17. 


□ 


Discussion 

Brands’s  withdrawal  protocol  is  not  all-protective  under  abortion  mode.  The  violation  of  protection 
still  results  from  unreliable  communication  channels,  and  not  premature  terminations  of  local 
executions. 

Surely,  if  O  terminates  its  local  execution  before  sending  P  a  message,  P  will  not  generate 
a  substrate  and  will  not  even  contact  P.  If  P  terminates  its  local  execution  before  sending  P 
the  signature,  P  will  not  acquire  a  new  coin,  but  neither  will  P  deduct  from  P’s  account.  If  P 
terminates  its  local  execution  before  sending  the  substrate,  P  again  does  not  get  contacted.  In  all 
these  cases,  no  one’s  interest  is  hurt. 

If  P  terminates  its  local  execution  after  sending  the  substrate,  but  before  receiving  the  signature, 
P  may  deduct  from  P’s  account  without  P  receiving  a  signature.  We  say  “may”  instead  of  “will” 
because  the  substrate  may  get  lost  in  transmission  and  never  trigger  a  local  withdrawal  processing 
at  P.  In  any  case,  P’s  interests  are  not  hurt. 
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5.6.4  Summary 

We  summarize  our  findings  in  Table  5.1.  All-protection  is  guaranteed  in  entries  with  a  a/.  Some 
entries  come  with  briefings  of  relevant  facts.  The  table  shows  that  Brands’s  withdrawal  protocol 
relies  critically  on  reliable  communication  channels. 


compliance 

abortion 

deception 

Channel  Failures 

(1) 

a) 

(i) 

No  Channel  Failures 

V 

V(2) 

v/(3) 

1.  P-protection  is  violated  if  the  signature  sent  by  B  does  not  get  to  P. 

2.  B  executes  signature  sending  and  account  deduction  atomically.  Its  premature  termi¬ 
nations  are  inconsequential. 

If  O  terminates  prematurely,  P  will  not  proceed  with  the  protocol,  and  no  substrate 
will  be  sent  to  B. 

If  P  terminates  her  execution  before  sending  B  the  substrate,  no  signature  is  issued, 
and  no  account  is  deducted.  If  P  terminates  her  execution  after  sending  the  substrate, 
but  before  receiving  the  signature,  no  harm  (except  to  herself)  can  be  made. 

3.  According  to  Tbw  and  Tow ,  neither  B  nor  O  deceives.  P’s  deceptions  do  not  hurt  P’s 
interests;  they  hurt  her  own  interests  in  withdrawal  transactions  and  P’s  interests  in 
deposit  transactions. 

Table  5.1:  Summary  table  for  the  withdrawal  protocol 

5.7  Analysis  of  The  Payment  Protocol 

5.7.1  Protection  under  Deception  Mode 

In  this  subsection,  we  analyze  Brands’s  payment  protocol  under  deception  mode.  We  first  analyze 
it  with  respect  to  P-protection,  then  with  respect  to  P-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  if  II  is  Brands’s  payment  protocol,  then  to 
analyze  it  with  respect  to  P-protection  under  deception  mode,  we  need  to  analyze  all  executions 
in  P(n)c  and  trustworthy  executions  in  P(II)p.  We  do  so  in  Prop.  5.22  and  5.19  respectively. 

Proposition  5.19  Let  II  be  Brands ’s  payment  protocol,  a  be  an  execution  in  P(II)p,  T  be  the  trust 
assumptions  II  makes,  and  Pp  be  P ’s  protection  property  as  specified  in  Section  5.4-2  (p.  115).  Then 

a  \ =*  T  implies  a  \=*  Pp. 

Analysis:  In  what  follows,  <hp,  and  $PE1  are  subformulas  of  Pp  as  specified  in  Section  5.4.2, 
and  <7  =  so  ei  sj ...  is  a  trustworthy  execution.  Because  o  is  an  execution  of  II,  so  satisfies  IPs 
initial  condition  lp.  Examining  lp ,  we  see  that 

a  =  [Qp/yuVip/y2,  V2p/y3,  Oo/yi,  Po/i/s,  tfA,  0o/w1,uo/w2,  U. comp^/xi,  u.eomp2/x2) 
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is  a  substitution  such  that  So  b 

Next,  let  Si  be  a  state  in  a  such  that  st  (=  $pp<y.  That  is,  sz  \=  v0  MSP  U  MS0.  We  would  like 
to  show  that  there  exist  a  state  Sj ,  j  >  i,  such  that 

if  the  communication  channels  are  reliable  in  the  system. 

1.  From  so  f=  27,  we  know  that 

So  b  e*  MS0. 

Thus,  if  s,-  |=  v0  MSP  U  MS0,  it  must  be  the  case  that  v0  was  deleted  from  MS0.  That  is, 

Si  |=  delete^)  6  H°.  (5.7) 

From  expression  5.7  and  trust  assumption  Top,  we  can  conclude  that  there  exist  messages 
m\\  t-chal  and  m2  :  t.pcert ,  such  that 

Si  b  receive (JP,  mi)  G  H°  A  send(P,  m2)  G  H°  A  ??72  =  pcert(7ni,  0O,  vQ).  (5.8) 

2.  From  Lemma  5.20,  the  fact  that  S{  |=  receive(P,  mi)  G  H°  (expression  5.8,  step  1),  and  the 
fact  that  P  behaves  compliantly  in  cr,  we  can  conclude  that 

Si  b  receive (P,  ug)  G  HE.  (5.9) 

3.  From  expression  5.8  (step  1)  and  Lemma  5.21,  we  conclude  that  there  exists  a  state  sf*/,  i*  >  i, 
and  a  rights  certificate  7723,  such  that 

S{t  b  receive (P,  m3)  G  HE,  (5.10) 

and 

m3  =  rcert(pcert(rai,  0Q,  i/0),  0P,  vlp,  i/2p). 

And  it  is  straightforward  to  see  that 

vrcert(m3,mi,  w).  (5-11) 

Since  P  behaves  compliantly  in  cr,  we  know  that  mx  is  the  challenge  P  received  from  P. 
Thus,  we  know  that 

sxt  b  send(P,  mi)  G  HE. 

4.  Examining  P’s  local  protocol,  we  see  that  send^ (P,  m\)  must  have  resulted  from  an  appli¬ 
cation  of  PP&3,  which  prescribes  sending  a  challenge  derived  from  P’s  id  ie  and  a  challenge 
seed  newly  generated. 

(a)  If  P  behaves  compliantly,  we  would  have 

su  b  :  tjcs  |  mx  =  chal(ie,  x)  A  z  G*  MSE.  (5.12) 

And  from  expressions  5.9,  5.10,  and  5.12,  we  would  obtain 

Si>  |=  $pEla, 

as  we  would  like. 
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(b)  But  <7  is  a  deceptive  execution,  and  P  may  not  have  derived  mj  from  its  own  id.  Thus, 
it  is  possible  that 

\=PX  :  t-.cs  |  mi  =  chal(ie,a:).  (5.13) 

From  expressions  5.11  and  5.13,  we  can  now  conclude  that 

jBx  :  t.cs  |  vrcertp(m3,chal(fe,a;),u). 


□ 


Bearing  in  mind  what  $p,  and  $pEl  specify  (Section  5.4.2),  the  analysis  of  Prop.  5.19  shows 
that  P’s  losing  the  ability  to  provide  rights  certificates  for  a  coin  during  a  payment  transaction 
does  not  always  entail  P’s  acquiring  the  rights  to  the  coin,  even  if  communication  channels  are 
reliable  in  the  system.  Effectively,  this  means  that  the  value  P  relinquishes  is  not  transferred  to 
E,  but  vanishes  instead. 

Clearly,  if  the  communication  channel  between  P  and  E  can  go  down,  the  rights  certificate  P 
sends  to  E  (presumably  transferring  the  rights  to  the  coin  from  P  to  E)  can  get  lost  in  transmission. 
But  even  if  the  communication  channels  are  reliable  and  E  receives  the  rights  certificate,  E  may 
still  not  acquire  the  rights  to  the  coin.  This  is  so  because  E  may  deceive  and  use  something  other 
than  its  own  id  to  generate  the  challenge.  Rights  certificates  generated  in  response  to  challenges 
that  do  not  embed  P’s  id  do  not  give  P  the  rights  to  the  coin.  Note  that  these  problems  exist  even 
if  O  behaves  as  trusted.  If  O  does  not  behave  as  specified  in  Top,  and  consumes  vQ  to  produce  a 
protocertificate  different  from  that  prescribed,  P  has  a  different  problem:  the  protocertificate  she 
receives  will  not  pass  the  validity  check,  and  no  rights  certificate  will  be  generated. 

The  following  two  lemmas  appear  in  our  analysis  of  Prop.  5.19.  Lemma  5.20  says  that,  in  com¬ 
pliant  executions  and  deceptive  executions  where  P  behaves  compliantly,  if  O  receives  a  challenge 
from  P,  then  P  must  have  received  a  coin  from  P. 

Lemma  5.20  Let  II  be  Brands’s  payment  protocol,  o  be  an  execution  in  P(II)p  U  E(Yl)c ,  and  s t- 
be  a  state  in  a  such  that 

Si  |=  3a:  :  t-chal  |  receive (P,  a:)  G  H°. 

Then, 

Si  |=  3a:  :  tsubs  X  tseal  |  receive (P,  x)  G  HE. 


Proof:  By  straightforward  backchaining,  using  the  protocol  rules  and  the  fact  that  messages  need 
to  be  sent  before  they  can  be  received. 

□ 

Lemma  5.21  says  that,  in  compliant  executions  and  deceptive  executions  where  P  behaves 
compliantly,  if  the  communication  channels  are  reliable,  then  once  O  sends  P  the  expected  proto¬ 
certificate,  P  will  receive  a  rights  certificate. 

Lemma  5.21  Let  II  be  Brands ’s  payment  protocol,  o  be  an  execution  in  E(U)p  U  E(U)C,  90  and 
v0  be  numbers  as  specified  in  Tv ,  and  Sj  be  a  state  in  o  such  that 

Si  \=  3aq  :  t-chal,x 2  :  t-pcert  |  receive (P,  x  1)  G  H°  A  send(P,  3:2)  G  H°  A  xi  —  pcert(aq,  60,  uQ). 
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Then,  there  exists  a  state  Sj,j  >  i,  such  that 

Sj  f=  3x  :  t.rcert  |  recei ve(P,x)  G  HE, 
if  the  communication  channels  are  reliable. 

Proof: 

1.  Let  mj:  t.chal ,  m2  :  t-pcert  be  messages  such  that 

s,  |=  receive(P,  m{)  G  H°  A  send(P,m2)  G  H°  A  m2  =  pcert(mi,  60,  u0).  (5.14) 

2.  From  S{  f=  receive  (P,  1 )  G  H°  (expression  5.14),  we  conclude,  by  straightforward  backchain- 

ing,  that 

Si  1=  receive(P,  mi)  G  Hp.  (5.15) 

3.  If  communication  channels  are  reliable,  we  can  conclude,  from  Si  (=  send  (P,m2)  G  H°  (ex¬ 
pression  5.14),  that  there  exists  a  state  s,<,  i'  >  i,  such  that 

Si>  |=  receive(0,  m2)  G  Hp.  (5.16) 

4.  From  expressions  5.15  and  5.16,  and  the  fact  that  m2  =  pcert(mi,  6a,  v0),  we  can  conclude 
that  there  exists  a  state  i"  >  i',  such  that 

Si"  t=  send(P,  rcert(m2, 9P,  vlp,  o2p))  G  Hp.  (5.17) 

5.  If  communication  channels  are  reliable,  we  can  conclude,  from  expression  5.17,  that  there 
exists  a  state  s,/»,  iw  >  i",  such  that 

Si m  [=  receive(P,  rcert(m2,  0p,  v\v,  ^2p))  G  HE. 


□ 

Prop.  5.22  concerns  maximal  compliant  executions.  These  executions  are  trustworthy  and  have 
compliant  local  executions  of  P  and  E.  Its  analysis  is  identical  to  that  of  Prop.  5.19,  except  for 
the  last  step. 

Proposition  5.22  Let  n  be  Brands’s  payment  protocol,  o  be  an  execution  in  E(Y[)C ,  and  Pp  be 
P’s  protection  property  as  specified  in  Section  5-4.2  (p.  115).  Then 

o  f=*  Pp- 

Analysis:  The  first  part  (steps  1  -  3)  of  this  analysis  is  identical  to  that  of  Prop  5.19.  Under 
compliance  mode,  we  reach  a  different  conclusion: 

4.  Since  E  behaves  compliantly,  we  conclude  that  mi  =  chal(fe,m6),  where  m6  is  a  challenge 
seed  newly  generated  by  E.  Finally,  we  have 

Si’  1=  me  G*  MSe  A  vrcert(mi,  chal(*e,  me),  u). 
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□ 


The  analysis  above  shows  that  the  only  problem  P  faces  in  maximal  compliant  executions  is 
unreliable  communication  channels,  which  can  prevent  E  from  receiving  the  rights  certificate  sent 
by  P. 

From  Prop.  5.19  and  5.22,  we  can  derive  the  following 

Corollary  5.23  Brands ’s  payment  protocol  is  not  P -protective  under  deception  mode,  even  if  the 
communication  channels  are  reliable. 


Next  we  address  .^-protection.  Like  in  the  analysis  of  P-protection ,  we  analyze  deceptive  and 
compliant  executions  in  turn. 

Proposition  5.24  Let  II  be  Brands’s  payment  protocol,  o  be  an  execution  in  P(II)£,  and  PB  be 
E ’s  protection  property  as  specified  in  Section  5-4-2  (p.  115).  Then 

*  K  PPE- 

Proof:  In  what  follows,  and  $PB  are  subformulas  of  PB,  as  specified  in  Section  5.4.2. 

1.  Let  Si  be  a  state  in  a,  and  mi  :  tsubs,  m2:  t.seal ,  m3  :  t.rcert,  and  m4:  t.chal  be  messages 
such  that 

Si  (=  §pE2[mi/xi,...,  m4/x4]. 

Then, 

Si  (=  send(P,  m4)  €  HE  A  receive  (P,  m3)  e  HE  A  vrcert(m3,  m4,  mi).  (5.18) 

2.  SendB(P,  m4)  (expression  5.18)  could  have  resulted  only  from  an  application  of  RPes .  And 
since  E  behaves  compliantly  in  a,  we  know  that 

m4  =  chal(ie,  ms), 

where  ms  is  a  newly  generated  challenge  seed. 

3.  From  vrcert(m3,m4,mi),  we  know  that 

m3  =  rcert(pcert(m4,  — ,  — ),  — ,  — ,  -). 

And  since  m5  ^  T,  we  know  that  m4  g*  A,  which  implies  that  m3  A. 


□ 

Bearing  in  mind  what  and  <frpB  specify  (Section  5.4.2),  the  proof  of  Prop.  5.24  shows  that 
if  E  accepts  a  coin  and  an  accompanying  rights  certificate,  then  E  must  have  been  given  the  rights 
to  the  coin,  and  the  rights  certificate  will  not  be  found  in  P’s  deposit  database.  E  is  given  the 
rights  to  the  coin  because  the  rights  certificate  he  accepts  can  be  checked  against  his  challenge  (the 
one  he  presented  to  P),  and  this  challenge  embeds  P’s  id.  The  rights  certificate  will  not  be  found 
in  P’s  deposit  database  because  it  embeds  the  challenge  seed  embedded  in  P’s  challenge,  and  this 
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challenge  seed  is  different  from  all  those  E  has  used  before.  Note  that  Prop.  5.24  holds  independent 
of  trust  assumptions  or  reliability  of  communication  channels. 

Of  course,  P  may  deceive  in  executions  in  E(U)^ ,  and  send  E  invalid  coins  and  rights  cer¬ 
tificates.  E  will  not  be  fooled  however,  because  he  checks  their  validity  before  accepting  them. 
Validity  conditions  checked  by  E  (expressed  by  predicates  vseal  and  vrcert)  are  included  in  <f>^2 . 

Prop.  5.25  concerns  maximal  compliant  executions.  Our  proof  of  Prop.  5.24  is  readily  applicable 
here  because  it  only  relies  on  the  fact  that  a  has  compliant  local  executions  of  E ,  a  condition  satisfied 
by  maximal  compliant  executions. 

Proposition  5.25  Let  If  be  Brands’s  payment  protocol,  a  be  an  execution  in  E{H)C ,  and  be 
E’s  protection  property  as  specified  in  Section  5./,. 2  (p.  115).  Then 

a  b*  PI- 

From  Prop.  5.24  and  5.25,  we  can  derive  the  following 
Corollary  5.26  Brands’s  payment  protocol  is  E-protective  under  deception  mode. 

Theorem  5.27  summarizes  the  results  in  this  subsection: 

Theorem  5.27  Brands’s  payment  protocol  is  not  all-protective  under  deception  mode,  even  if  the 
communication  channels  are  reliable. 

Proof:  From  Cor.  5.23  and  5.26. 


□ 


Discussion 

According  to  our  analysis,  P’s  interests  are  not  protected  under  deception  mode  even  if  commu¬ 
nication  channels  in  the  system  are  reliable.  In  fact,  E  can  deceive  and  send  P  a  challenge  that 
embeds  a  bogus  principal  id.  This  will  cause  P  to  generate  a  bogus  rights  certificate,  which  will 
consume  P’s  one-time  capability  of  generating  rights  certificates  for  a  coin,  but  will  not  give  E,  or 
any  other  principal,  the  rights  to  the  coin.  Effectively,  the  corresponding  coin  is  rendered  worthless 
because  P  can  no  longer  spend  it,  and  no  one  acquired  the  rights  to  deposit  it. 

There  are  countermeasures  against  this  threat,  however.  For  example,  if  P  can  generate  chal¬ 
lenges  herself,  then  she  will  not  risk  generating  rights  certificates  for  bogus  challenges.  To  implement 
this  approach,  E  can  send  P  only  a  challenge  seed  ( t ),  and  allow  P  to  look  up  E’s  id  in  some  trusted 
public  directory.  Using  t  and  E’s  id,  P  can  then  generate  a  challenge  herself,  and  be  sure  that  it 
embeds  a  valid  E  id.  This  approach  does  not  affect  E-protection,  since  E  can  always  reconstitute 
challenges  himself  to  check  the  validity  of  corresponding  rights  certificates. 

Alternatively,  if  message  receipts  are  non-repudiable,  P  can  show  to  a  third  party  the  challenge 
she  received  from  E,  and  prove  that  E  is  responsible  for  the  loss  and  therefore  should  be  the  only 
one  held  accountable  for  it.  Under  this  second  approach,  E’s  deception  is  no  longer  an  act  of 
sabotage  inconsequential  to  E.  Instead,  it  will  be  an  assault  to  E’s  own  interests. 

Aside  from  E’s  deceptions,  unreliable  communication  channels  and  O’ s  violation  of  trust  as¬ 
sumptions  can  also  compromise  P-protection.  There  are  countermeasures  for  these  threats  too.  To 
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safeguard  against  loss  of  rights  certificates  due  to  unreliable  communication  channels,  P  can  keep 
a  copy  of  the  rights  certificate  and  send  it  later  to  P,  assuming  that  E  is  willing  to  receive  it.  To 
safeguard  against  P’s  inability  to  generate  an  appropriate  rights  certificate  due  to  O’ s  violation  of 
Top ,  we  can  use  the  same  measure  suggested  to  counteract  O’s  violation  of  Tow  in  the  withdrawal 
protocol.  It  consists  of  having  B  keep  a  record  of  the  signatures  it  issued  with  their  respective 
requesters  during  the  withdrawal  protocol.  When  P  finds  out  that  she  is  unable  to  spend  a  coin 
because  of  O,  she  can  then  go  to  B  to  revoke  the  corresponding  coin  and  get  a  refund. 

Next,  we  address  P-protection .  According  to  our  analysis,  it  is  independent  of  link  reliability 
or  trust  assumptions,  and  solely  relies  on  P’s  behaving  compliantly.  In  Brands’s  ecash  system,  P 
is,  thus,  much  less  vulnerable  than  P. 

5.7.2  Protection  under  Compliance  Mode 

In  this  subsection,  we  analyze  the  protocol  under  compliance  mode.  To  verify  whether  the  protocol 
is  all- protective  under  compliance  mode,  we  need  to  verify  whether  both  P’s  and  P’s  interests  are 
protected  in  maximal  compliant  executions.  These  results  have  already  been  verified  in  Subsec¬ 
tion  5.7.1,  however.  According  to  Prop  5.22  and  5.25, 

Theorem  5.28  Brands  ’s  payment  protocol  is  all-protective  under  compliance  mode,  if  the  commu¬ 
nication  channel  between  P  and  E  is  reliable. 

Discussion 

Brands’s  payment  is  not  all-protective  under  compliance  mode.  Like  under  deception  mode,  it  is 
P-protective,  but  not  P-protective.  It  is  P-protective  because  P  depends  on  nothing  other  than 
his  own  compliance  to  the  protocol  to  protect  his  interests.  It  is  not  P-protective  because  P  still 
risks  losing  the  only  rights  certificate  she  can  generate  due  to  unreliable  communication  channels. 

5.7.3  Protection  under  Abortion  Mode 

In  this  subsection,  we  analyze  the  protocol  under  abortion  mode.  Like  in  the  two  previous  subsec¬ 
tions,  we  need  to  verify  whether  the  protocol  is  both  P-protective  and  P-protective.  We  start  with 
P-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  to  verify  whether  II  protects  P’s  interests 
under  abortion  mode,  we  need  to  examine  all  executions  in  P(II)C  and  trustworthy  executions  in 
E{J\)p.  Here  we  focus  on  abortive  executions  only,  since  we  have  analyzed  compliant  executions 
(Prop.  5.22)  in  Section  5.7.1. 

Proposition  5.29  Let  n  be  B rands ’s  payment  protocol,  o  be  an  execution  in  P(n)p,  T  be  the  trust 
assumptions  n  makes,  and  Pp  be  P ’s  protection  property  as  specified  in  Section  5-4-2  (p.  115).  Then 

a  \=*  T  implies  o  |=*  Pp. 

Analysis:  A  quick  glance  over  the  property  Pp  allows  us  to  conclude  that  this  proposition  does  not 
hold:  P  can  terminate  his  execution  right  before  receiving  the  rights  certificate  from  P,  preventing 
$pEl  from  ever  becoming  true. 

□ 
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From  Prop.  5.22  (Section  5.7.1)  and  5.29,  which  jointly  address  P-protection  under  abortion 
mode,  we  derive  the  following 

Corollary  5.30  Brands’s  payment  protocol  is  not  P-protective  under  abortion  mode,  even  if  the 
communication  channel  between  P  and  E  is  reliable. 

Prop.  5.31  addresses  protection  of  E’s  interests  in  abortive  executions  and  can  be  proven  using 
the  proof  for  Prop.  5.24  (Subsection  5.7.1).  That  proof  is  applicable  here  for  a  reason  analogous  to 
the  one  given  for  Prop.  5.25. 

Proposition  5.31  Let  n  be  Brands’s  payment  protocol,  a  be  an  execution  in  E(JT)g,  and  P£  be 
E’s  protection  property  as  specified  in  Section  5-4.2  (p.  115).  Then 

°  \=*  Pi- 

From  Prop.  5.25  (Section  5.7.1)  and  5.31,  which  jointly  address  P-protection  under  abortion 
mode,  we  derive  the  following 

Corollary  5.32  Brands ’s  payment  protocol  is  E -protective  under  abortion  mode. 

Theorem  5.33  summarizes  the  results  in  this  subsection. 

Theorem  5.33  Brands’s  payment  protocol  is  not  all-protective  under  abortion  mode,  even  if  the 
communication  channel  between  P  and  E  is  reliable. 

Proof:  From  Cor.  5.30  and  5.32. 


□ 


Discussion 

Brands  s  payment  protocol  is  not  all-protective  under  abortion  mode.  Like  in  compliance  and 
deception  modes,  it  is  P-protective,  but  not  P- protective.  It  is  P-protective  because  P’s  protection 
property  is  only  concerned  with  the  validity  of  what  P  receives,  which  is  not  affected  by  P’s  or  O’ s 
premature  terminations. 

Brands  s  payment  protocol  is  not  P-protective,  however;  P’s  interests  can  be  compromised  not 
only  by  unreliable  communication  channels,  but  also  by  P’s  premature  termination.  Premature 
termination  models,  among  other  things,  P’s  refusal  in  receiving  a  rights  certificate  for  reason¬ 
able  (e.g.,  transaction  timeout)  or  unreasonable  reasons.  To  safeguard  her  interests  against  P’s 
premature  termination,  P  should  get  a  commitment  from  P  with  respect  to  accepting  the  rights 
certificate  before  she  asks  O  to  provide  the  protocertificate.  A  proof  of  this  commitment  will  force 
P  to  receive  the  rights  certificate  eventually,  or  hold  him  accountable  for  P’s  coin  loss. 

Note  that  the  problem  only  arises  if  O  deletes  v0,  but  P  does  not  receive  the  rights  certificate 
sent  by  P.  O  may  not  delete  v0,  however,  if  O  is  compromised.  Not  having  v0  deleted  means  that 
P  is  able  to  provide  another  rights  certificate  for  the  coin,  which  makes  the  loss  of  the  current  one 
inconsequential.  This  interesting  relationship  between  ua’ s  deletion  and  protection  of  P’s  interests 
is  captured  in  our  specification  of  Pfi  (Section  5.4.2).  In  an  execution  where  v0  is  not  deleted,  P£ 
is  vacuously  true  because  is  never  true. 
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5.7.4  Summary 

We  summarize  our  findings  in  Table  5.2.  All-protection  is  guaranteed  in  entries  with  a  y/ .  Some 
entries  come  with  briefings  of  relevant  facts. 


compliance 

abortion 

deception 

Channel  Failures 

(i) 

(i) 

(i) 

No  Channel  Failures 

V 

(2) 

(3) 

1.  Rights  certificates  sent  by  P  may  get  lost  in  transmission  and  not  reach  E. 

2.  E  may  terminate  his  execution  prematurely,  and  fail  to  receive  the  rights  certificate 
sent  by  P.  P-protection  is  violated  only  in  executions  where  O  deletes  u0,  however. 

3.  P  will  generate  a  bogus  rights  certificate  if  P’s  challenge  is  bogus.  According  to  Top, 

O  does  not  deceive. 

Table  5.2:  Summary  table  for  the  payment  protocol. 

As  is  shown  in  Table  5.2,  Brands’s  payment  protocol  is  quite  vulnerable:  it  is  all-protective 
only  if  all  parties  behave  compliantly  and  the  communication  channels  are  reliable.  P  and  E  are 
not  equally  vulnerable,  however.  In  fact,  only  P- protection  is  susceptible  to  attacks;  the  protocol 
is  P-protective  in  all  the  cases. 

P’s  vulnerability  results  from  her  ability  to  generate  only  one  rights  certificate  per  coin.  Unless, 
this  one-time  capability  is  used  to  generate  a  valid  certificate  that  is  eventually  received  by  P,  the 
value  borne  by  the  corresponding  coin  would  not  be  preserved  and  passed  to  P.  The  problem  is 
that  neither  the  generation  nor  the  delivery  of  this  certificate  is  entirely  under  P’s  control.  P  can 
make  P  generate  a  bogus  certificate  by  sending  her  a  bogus  challenge  (deception  mode);  or  P  can 
make  P  generate  a  certificate,  and  disappear  before  receiving  it  (abortion  mode) ;  finally,  a  valid 
certificate  may  simply  not  reach  a  willing  P  because  of  unreliable  communication  links. 

Note  that  P  would  be  less  vulnerable  if  she  could  generate  multiple  rights  certificates  per  coin. 
Unsuccessful  spendings  of  a  coin  -  due  to  bogus  or  missing  certificates  -  would  not  matter  in  this 
case  since  she  can  try  again.  Of  course,  this  also  means  that  a  dishonest  P  could  spend  a  coin  a 
second  time  even  if  the  first  attempt  were  successful. 

While  making  P  less  vulnerable,  P’s  ability  to  generate  multiple  rights  certificates  per  coin  does 
not  (arguably)  bring  unrecoverable  losses  to  P.  If  P  receives  a  coin  that  has  been  double-spent, 
the  double-spender’s  identity  can  presumably  be  revealed,  allowing  P  to  collect  the  due  amount 
off-line.  Of  course  P  may  simply  disappear  and  make  these  off-line  collections  impossible;  or  these 
collections  may  be  an  overhead  that  P  is  unable  or  unwilling  to  incur. 

Thus,  whether  or  not  to  allow  multiple  generations  of  rights  certificates  may  be  best  determined 
by  the  characteristics  of  a  system  (type  of  participants,  reliability  of  system  components,  etc).  For 
example,  if  the  payees  of  a  system  are  well-established  merchants  who  will  not  misbehave,  then 
the  one-time  restriction  is  not  as  harmful.  On  the  other  hand,  if  the  communication  channels  are 
unreliable  in  a  system,  but  all  participants  are  honest,  then  allowing  multiple  generations  of  rights 
certificates  seems  more  reasonable. 
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5.8  Analysis  of  The  Deposit  Protocol 

5.8.1  Protection  under  Deception  Mode 

In  this  subsection,  we  analyze  Brands’s  deposit  protocol  under  deception  mode.  We  first  analyze 
it  with  respect  to  5-protection,  then  with  respect  to  5-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  if  II  is  Brands’s  deposit  protocol,  then  to 
analyze  it  with  respect  to  5-protection  under  deception  mode,  we  need  to  analyze  all  executions 
in  £(II)C  and  trustworthy  executions  in  £(11)^.  We  do  so  in  Prop.  5.35  and  5.34  respectively. 

Proposition  5.34  Let  II  be  Brands’s  deposit  protocol,  o  be  an  execution  in  E( II) g,  and  PB  be 
B’s  protection  property  as  specified  in  Section  5-4.3  (p.  118).  Then 

o  (=*  PdB. 

Proof:  In  what  follows,  $dBl  and  $dB2  are  subformulas  of  P%  as  specified  in  Section  5.4.3;  s,-  is  a 
state  in  a;  and  m\\  tsubs  and  m2:  tseal  are  messages  such  that 

si  b  ^dBi[mi/xi,m2/x2}.  (5.19) 

We  would  like  to  prove  that 

Si  f=  vseal(mi,  m2)  &&)  A  mi.compj  0*  A. 

1.  From  expression  5.19,  we  have 

Si  |=  receive(£’,  ?n1m2 - )  €  HB  A  credit(-)  £  HB, 

where  credit(-)  must  have  resulted  from  an  application  of  RDb2. 

2.  If  RDb2  was  applied,  then  its  antecedent  must  be  true  at  a  state  Sj ,  j  <  i.  And  given  that 
there  can  be  only  one  event  of  type  receive^,  x),  x  :  t.subs  x  t.seal  x  t.cs  x  t.rcert,  in  o 
(Lemma  5.2),  it  must  be  the  case  that 

S{  |=  vseal(mi,  m2,  kb)  A  :  t-deposit  £  A  |  a^.subsComp  =  mj.compj.  (5.20) 

3.  Since  each  entry  in  the  deposit  database  only  records  one  message  of  type  tsubsi,  and  this 
message  is  recorded  in  the  field  “subsComp”,  we  can  conclude  from  expression  5.20  that 

Si  )=  vseal(rai ,  m2,  kb)  A  mi.compj  A. 


□ 

Bearing  in  mind  what  $dBl  and  4>^2  specify,  the  proof  of  Prop.  5.34  shows  that  if  B  accepts  a  coin 
for  deposit,  then  the  coin  is  valid  and  has  not  been  deposited  before.  This  result  is  not  surprising 
because,  even  though  E  may  try  to  deposit  invalid  coins  or  coins  that  have  been  deposited  before, 
B  can  check  for  these  conditions,  and  reject  the  deposit  if  something  is  wrong. 

Note  that  we  analyzed  all  executions  in  E(Yl)B,  and  did  not  restrict  ourselves  to  just  trustworthy 
executions.  In  reality,  all  executions  in  E(Tl)%  are  trustworthy  in  this  case,  because  TBd  is  the  only 
trust  assumption  here,  and  all  executions  in  E(Yl)B  satisfy  it. 

Prop.  5.35  concerns  maximal  compliant  executions.  Our  proof  of  Prop.  5.34  is  readily  applicable 
here  because  it  only  requeries  that  o  has  compliant  local  executions  of  B ,  a  condition  satisfied  by 
maximal  compliant  executions. 
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Proposition  5.35  Let  n  be  Brands’s  deposit  protocol ,  o  be  an  execution  in  E( Tl)C ,  and  Pg  be  B ’s 
protection  property  as  specified  in  Section  5.4.3  (p.  118).  Then 

a  (=*  PB- 

From  Prop.  5.34  and  5.35,  we  can  derive  the  following 
Corollary  5.36  Brands’s  deposit  protocol  is  B-protective  under  deception  mode.  ■ 

Next  we  address  E-protection.  As  with  the  analysis  of  E-protection,  we  need  to  analyze  both 
deceptive  and  compliant  executions.  We  start  with  deceptive  ones. 

Proposition  5.37  Let  II  be  Brands’s  deposit  protocol,  a  be  an  execution  in  E{Jl )^,  T  be  trust 
assumptions  II  make,  and  PdE  be  E’s  protection  property  as  specified  in  Section  5.4*3  (p.  118). 
Then 

<j  \ T  implies  o  \=*  Pg. 

Analysis:  Let  a  be  a  trustworthy  execution  in  i?(II)^,  and  S{  be  a  state  in  a  where  there  exist 
messages  m\  :  Esubs ,  m2  :  Eseal ,  m3:  Ecs  and  :  tjrcert ,  such  that 

si  1=  $B3[mi/a;i,...,m4/a:4].  (5.21) 

We  would  like  to  prove  that  there  exists  a  state  Sj  in  o,j  >  i,  such  that 

Sj  |=  credit (ace)  €  HB  V  9P  €*  MSB. 


1.  Expression  5.21  says  that 

Si  |=  receive(E,mi . .  .m4)  €  Hb  A  vseal(mi,  m2,  h)  A 
vrcert(m4,  chal(ace.id,  m3),  mi)  A  m4  A. 

Now,  let  Si',  i!  <  i,  be  a  state  in  a  such  that 

sp  |=  last(HB)  =  receive (E,  m\ . . .  m4). 


There  are  two  possibilities: 

(a)  ^£5  :  t -deposit  6  A  |  a:5.subsComp  =  mi.comp!,  or 

(b)  3x5  :  t -deposit  €  A  |  x5.subsComp  =  mi.comp!. 

We  examine  each  in  turn. 

2.  If  (la)  is  true,  then  the  event  credit(oce)  will  eventually  take  place,  according  to  trust  as¬ 
sumption  TBd.  That  is,  there  exists  a  state  s,-»  in  o,  i"  >  i',  such  that 

Sj»  |=  credit  (ace)  G  HB. 

3.  If  (lb)  is  true,  then  B  terminates  its  local  execution  without  the  event  credit(ace).  We  show 
below  that  this  scenario  does  not  guarantee  that  9P  be  revealed. 
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4.  Let  e:  t .deposit  be  the  entry  in  the  deposit  database  such  that 

Sji  \=  e.subsComp  =  mi.compj. 


(5.22) 


Given  that  m4  A,  it  must  be  the  case  that 


e.rc  /  1114. 

Apparently  B  can  apply  the  function  revea.l_sec  to  messages  e.rc,  m 4,  and  0o  to  reveal  P’s 
account  secret  6p.  But  the  equality  reveal_sec(e.rc,  m4,  90)  =  6P  holds  only  if  e.rc  and  m4  are 
rights  certificates  concerning  the  same  coin,  which  is  not  guaranteed  by  the  equality  5.22  if 
P  can  deceive. 

We  conclude  that  this  proposition  does  not  hold. 


□ 

Prop.  5.37  does  not  hold.  Bearing  in  mind  what  $dB3  and  specify  (Section  5.4.3),  its  analysis 
shows  that,  when  B  receives  a  valid  coin  and  a  not-yet-submitted  rights  certificate  from  a  rightful 
P,  it  is  not  necessary  that  P’s  account  will  be  credited  or  P’s  identity  will  be  revealed.  Intuitively, 
this  means  that  a.  coin  that  passes  all  verifications  recommended  in  the  payment  protocol  can  still 
be  worthless. 

This  result  is  unexpected,  because  it  contradicts  what  is  claimed  in  [14].  According  to  [14],  there 
are  three  possible  outcomes  when  P  tries  to  deposit  a  coin  that  he  has  rights  to  (Section  5.2.4).  If 
the  coin  is  not  found  in  the  deposit  database,  B  simply  deposits  it,  and  P’s  account  is  credited. 
If  the  coin  is  found  in  the  deposit  database,  but  its  accompanying  rights  certificate  from  the 
database  differs  from  the  one  being  submitted,  then  B  uses  the  two  rights  certificates  to  reveal 
the  account  secret  embedded  in  them,  thus  retrieving  P’s  identity.  Finally,  if  both  the  coin  and 
the  rights  certificate  being  submitted  are  found  in  the  deposit  database,  B  simply  ignores  this 
deposit  attempt.  Since  Prop.  5.37  assumes  that  the  rights  certificate  being  submitted  had  not  been 
submitted  before,  we  should  have  been  able  to  conclude  that  the  deposit  attempt  yields  the  first 
or  the  second  outcomes.  That  is,  either  P’s  account  is  credited  or  P’s  identity  is  revealed. 

This  contradiction  results  from  an  inconsistency  between  what  can  actually  happen  in  the 
system  under  deception  mode  and  what  Brands  assumes.  To  follow  the  rest  of  this  discussion,  the 
reader  should  be  familiar  with  the  materia]  presented  in  Sections  5.2.2,  5.2.3,  and  5.2.4. 

Concretely,  Brands  assumes  that  two  valid  coins  are  identical  if  the  first  components  of  their 
substrates  are  identical.  That  is,  if  (uj,  u2)  and  ( ii\ ,  w3)  are  respectively  the  substrates  of  two  valid 
coins  c  and  c',  then 

ui  =  u[  — >■  c  =  c'. 

Or  simply, 

ui=u\  ->  {ui,u2)  =  (u[,  u'2).  (5.23) 

This  is  true  if  substrates  are  always  generated  as  prescribed.  According  to  the  withdrawal 
protocol  (Section  5.2.2),  all  coin-specific  secrets  (v\ p,  and  vQ )  embedded  in  substrates  should 

be  randomly  generated  for  each  new  substrate.  Since  no  two  randomly  generated  numbers  are 
equal,  it  is  impossible  to  have  two  different  substrates  sharing  a  same  V\v,  and  therefore  a  same 
first  component.  That  is, 

(«1,“2)  7^  (ul,  *4) 
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which  is  equivalent  to  expression  5.23.  We  know  that  Brands  makes  the  assumption  above  because 
B’s  deposit  database  only  keeps  the  first  component  of  a  coin’s  substrate  when  the  coin  is  deposited. 

Withdra.wers  can  deceive,  and  not  generate  substrates  exactly  as  prescribed,  however.  For 
example,  they  may  embed  in  a  new  substrate  both  secrets  generated  at  random  and  ones  already 
used  in  other  substrates.  Thus,  it  is  possible  for  P  to  generate  a  substrate  (u[,u'2)  where 

{u'i  =  subsi  (0P,  V\p,  60 ),  and 
«2  =  subs2(i/lp ,  v'2p,  0o,  v'0), 

with  randomly  generated  and  v'0 ,  and  a  “recycled”  v\p  from  a  pre-existing  substrate  (ui,u2), 

{U\  =  subsi(6p,v\p,60),  and 
u2  =  subs2(vip,v2p,60,vZ). 


In  this  case,  we  have 

(ux,u2)  ^  (u[,  u'2)  A  Ml  =  u[. 

Prop.  5.37  does  not  hold  exactly  because  of  the  deception  depicted  above.  More  specifically, 
B  would  not  credit  £”s  account  or  be  able  to  reveal  P’s  identity  if  the  coin  being  submitted  for 
deposit  has  not  been  deposited  before,  but  shares  the  first  component  of  its  substrate  with  an 
already  deposited  coin.  Fig.  5.6  shows  two  such  coins  and  their  accompanying  rights  certificates. 


c  : 


Substrate  :  (wi,  u2), 


m  =  subsi(0p,  z/ip,  0O),  and 
u2  =  subs2(^ip,z/2pA>^), 


Accompanying  rights  certificate  :  rc  =  rcert(pcert(cft,  0O,  z^0),  0p,  Vip,  v2v) 


c'-  Substrate  •  (u'  u>)  (  ui  =  s»bsi(ffp>  ±nd 

c  .  Substrate  .  (uvu2),  j  ^  =  subs2( ^  ^  ^  ^ 

Accompanying  rights  certificate  :  rc'  =  rcert(pcert(c/i/,  0o,  v'0),6P,  v\p,  v2p) 


Figure  5.6:  Examples  of  two  different  coins  sharing  the  first  component  of  their  substrates. 

If  c  has  been  deposited,  then  B  will  not  accept  d  for  deposit  and  credit  E”s  account  because 
U\  =  u[.  But  B  cannot  apply  the  function  reveal _sec  (Def.  5.1)  to  rc  and  rc’ to  reveal  0P  either, 
because  unless  rc  and  rc’  differ  only  in  the  challenge  they  embed,  reveal_sec(rc,  rd,  0o)  does  not 
yield  0p.  In  Fig.  5.6,  rc  and  rc’  embed  not  only  different  challenges  ( ch  ^  ch '),  but  also  some 
different  coin-specific  secrets  ( v0  ^  v'0  and  v2p  ^  v'2p) . 

Because  Prop.  5.37  does  not  hold,  we  can  skip  analyzing  compliant  executions,  and  conclude 
that 

Corollary  5.38  Brands’s  deposit  protocol  is  not  E -protective  under  deception  mode. 

Theorem  5.39  summarizes  the  results  in  this  subsection: 
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Theorem  5.39  Brands’s  deposit  protocol  is  not  all-protective  under  deception  mode. 
Proof:  From  Cor.  5.36  and  5.38. 


□ 


Discussion 

According  to  our  analysis,  Brands’s  deposit  protocol  is  B-protective  under  deception  mode.  This 
is  not  surprising,  because  B  has  complete  control  over  the  depositing  procedure,  and  cannot  be 
tricked  into  depositing  invalid  coins  or  coins  that  have  been  deposited  before. 

What  is  surprising  are  that  the  deposit  protocol  is  not  E-protective  and  why  it  is  not.  According 
to  our  analysis,  E-protection  is  not  compromised  by  unreliable  communication  channels  or  B’s 
deceptions.  It  is  not  affected  by  unreliable  communication  channels  because  E  can  keep  a  copy 
of  what  he  submits  to  B ,  and  re-submit  it  later  if  his  submission  gets  lost  in  transmission.  It  is 
not  affected  by  B’s  deceptions  because  B  is  trusted  not  to  commit  the  only  deception  that  could 
compromise  E-protection. 

Instead,  E-protection  is  compromised  by  P’s  deception  earlier  in  the  withdrawal  protocol,  when 
the  coin  was  withdrawn!  More  specifically,  P  can  deceive  and  withdraw  a  perfectly  valid  coin  that 
B  may  not  accept  for  deposit,  and  whose  accompanying  rights  certificate  may  not  be  useful  to  reveal 
P’s  identity  when  E  tries  to  deposit  the  coin.  The  discussion  following  the  analysis  of  Prop.  5.37 
shows  an  example  of  such  a  coin.  We  say  may  instead  of  will  because  what  actually  happens 
depends  on  the  result  of  a  race  condition  involving  coins  c  and  c'  in  Fig.  5.6.  If  c  is  submitted  for 
deposit  first,  d  is  useless.  However,  if  d  is  submitted  first,  it  will  be  deposited,  and  c  will  be  the 
useless  one. 

Note  that  this  coin  is  interesting  because  it  is  a  perfectly  valid  new  coin  at  its  generation,  even 
though  P  has  deceived  in  its  generation.  P  herself  does  not  benefit  from  the  deception,  because 
she  “pays  for”  the  coin  when  she  withdraws  it  (her  account  is  deducted),  and  she  is  able  to  spend 
it.  E  is  the  only  one  hurt  in  this  case  because  the  coin  he  received  is  completely  useless.  Thus,  this 
deception  is  effective  only  for  sabotage,  but  not  for  bringing  P  monetary  gains. 

Finally,  even  though  E-protection  is  compromised  by  P’s  deception  in  the  withdrawal  protocol, 
the  real  problem  lies  in  the  design  of  the  deposit  protocol,  and  can  be  fixed  simply  by  using  both 
components  of  a  coin’s  substrate  to  tell  whether  or  not  a  coin  has  been  deposited.  B  would  need 
to  record  whole  substrates  in  the  deposit  database  in  the  fixed  protocol. 

5.8.2  Protection  under  Compliance  Mode 

In  this  subsection,  we  analyze  the  protocol  under  compliance  mode.  To  veri fy  whether  the  protocol 
is  all-protective  under  compliance  mode,  we  need  to  verify  whether  both  B’s  and  E’s  interests  are 
protected  in  maximal  compliant  executions.  Prop.  5.35  (Section  5.8.1)  shows  that  Brands’s  deposit 
protocol  is  P-protective  in  maximal  compliant  executions;  Prop.  5.40  shows  that  it  is  E-protective. 

Proposition  5.40  Let  n  be  Brands’s  deposit  protocol,  a  be  an  execution  in  E(Y[)C ,  and  Pg  be  E’s 
protection  property  as  specified  in  Section  5-4-3  (p.  118).  Then 

°  \=*  Pi 
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Proof:  The  first  part  (steps  1  -  3)  of  this  analysis  is  identical  to  that  of  Prop  5.37.  Under 
compliance  mode,  we  reach  a  different  conclusion: 

4.  Let  e:  L deposit  be  the  entry  in  the  deposit  database  such  that 

Sjt  |=  e.subsComp  =  mi.comp^  (5.24) 

Given  that  A,  it  must  be  the  case  that 

e.rc  /  7714. 

P  can  now  apply  the  function  revea,l_sec  to  messages  e.rc,  7774,  and  0o  to  reveal  P’s  account  se¬ 
cret  0p.  We  know  that  reveal_sec(e.rc,  7774,  0o)  =  0P  because  e.rc  and  7774  are  rights  certificates 
concerning  the  same  coin.  We  know  this  last  fact  because  of  the  equality  in  expression  5.24, 
which  under  compliance  mode  means  that  7771  and  the  coin  associated  with  entry  e  are  iden¬ 
tical. 


□ 

From  Prop  5.35  and  5.40,  we  can  now  conclude 
Theorem  5.41  Brands  ’s  deposit  protocol  is  all-protective  under  compliance  mode . 

Discussion 

Brands’s  deposit  protocol  is  all-protective  under  compliance  mode.  Unlike  under  deception  mode, 
the  protocol  is  P-protective  here.  It  is  P-protective  because,  when  P  behaves  compliantly,  two  coins 
that  share  the  first  components  of  their  substrates  are  always  identical.  This  identity  prevents  the 
problem-causing  scenario  that  was  possible  under  deception  mode  from  occurring  here,  and  allows 
us  to  reach  the  following  conclusion.  When  a  coin  is  submitted  for  deposit,  the  first  component  of 
its  substrate  can  or  cannot  be  found  in  the  deposit  database.  In  the  first  case,  the  coin  is  accepted 
for  deposit  and  P’s  account  is  credited.  In  the  second  case,  the  coin  has  actually  been  deposited 
before,  and  the  two  available  rights  certificates  for  this  coin  can  be  used  to  reveal  0p. 

5.8.3  Protection  under  Abortion  Mode 

In  this  subsection,  we  analyze  the  protocol  under  abortion  mode.  Like  in  the  two  previous  subsec¬ 
tions,  we  need  to  verify  whether  the  protocol  is  both  P-protective  and  P-protective.  We  start  with 
P-protection. 

According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  to  verify  whether  II  protects  P’s  interests 
under  abortion  mode,  we  need  to  examine  all  executions  in  P(n)^  and  trustworthy  executions  in 
P( n)^.  Here  we  focus  on  abortive  executions  only,  since  we  have  analyzed  compliant  executions 
(Prop.  5.35)  in  Section  5.8.1. 

Prop.  5.42  can  be  proven  using  our  proof  for  Prop.  5.34,  since  that  proof  only  depended  on  the 
fact  that  P  behaves  compliantly. 

Proposition  5.42  Let  II  be  Brands’s  deposit  protocol ,  o  be  an  execution  in  P(II)g,  and  Pg  be 
B’s  protection  property  as  specified  in  Section  5. 1^.3  (p.  118).  Then 

o¥’H- 
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From  Prop.  5.35  (Section  5.8.1)  and  5.42,  which  jointly  address  5-protection  under  abortion 
mode,  we  derive  the  following 

Corollary  5.43  Brands’s  deposit  protocol  is  B -protective  under  abortion  mode. 

We  address  5-protection  next.  According  to  Defs.  2.25  and  2.26  in  Section  2.4.3,  to  verify 
whether  II  protects  5’s  interests  under  abortion  mode,  we  need  to  examine  all  executions  in  5(II)C 
and  trustworthy  executions  in  5(11)^.  Here  we  focus  on  abortive  executions  only,  since  we  have 
analyzed  compliant  executions  (Prop.  5.40)  in  Section  5.8.2. 

Prop.  5.44  can  be  proven  using  our  proof  for  Prop.  5.40,  since  that  proof  only  depended  on  5’s 
behaving  as  trusted. 

Proposition  5.44  Let  II  be  Brands  ’s  deposit  protocol,  a  be  an  execution  in  5 (14 )  ) .  and.  Pf,  be  E’s 
protection  property  as  specified  in  Section  5.4-3  (p.  118).  Then 

O  \=*  PdE- 

5’s  protection  property  is  satisfied  by  all  executions  in  5(n)^  because,  according  to  TBd,  the 
only  termination  that  could  violate  5|  (5’s  terminating  its  local  execution  right  before  it  should 
credit  5’s  account)  does  not  happen. 

From  Prop.  5.40  (Section  5.8.2)  and  5.44,  which  jointly  address  5-protection  under  abortion 
mode,  we  derive  the  following 

Corollary  5.45  Brands’s  deposit  protocol  is  E -protective  under  abortion  mode. 

Theorem  5.46  summarizes  the  results  in  this  subsection. 

Theorem  5.46  Brands  ’s  deposit  protocol  is  all-protective  under  abortion  mode. 

Proof:  From  Cor.  5.43  and  5.45. 


□ 


Discussion 

Brands’s  deposit  protocol  is  all-protective  under  abortion  mode.  5-protection  depends  only  on  5’s 
compliance  to  the  protocol,  while  5-protection  relies  on  5’s  behaving  as  trusted.  If  5  behaves  as 
trusted,  then  it  will  not  terminate  its  execution  in  the  middle  of  processing  deposit  requests,  and 
will  always  credit  5’s  account  if  the  coin  being  submitted  has  not  been  deposited  before. 

5.8.4  Summary 

We  summarize  our  findings  in  Table  5.3.  All-protection  is  guaranteed  in  entries  with  a  ^/;  5- 
protection  relies  on  TBd  in  entries  with  a  *.  The  table  shows  that  all-protection  does  not  depend 
on  reliable  communication  channels,  and  trust  assumptions  are  needed  only  under  abortion  mode. 
Note  that  Brands’s  deposit  protocol  is  not  all-protective  only  under  deception  mode,  where  5’s 
protection  property  can  be  violated. 
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compliance 

abortion 

deception 

Channel  Failures 

V 

y/  * 

(i) 

No  Channel  Failures 

V 

* 

(i) 

1.  .^-protection  is  guaranteed,  ^-protection  is  violated  by  P’s  deceptions  earlier  in  the 
withdrawal  protocol,  when  the  coin  was  withdrawn. 

Table  5.3:  Summary  table  for  the  deposit  protocol. 

In  all  entries,  the  protocol  is  B-protective  simply  because  B  has  complete  control  over  the 
deposit  procedure,  and  can  detect  all  of  P’s  deviations  before  accepting  the  deposit  request.  The 
protocol  is  B-protective  under  both  compliance  and  abortion  modes.  Under  deception  mode, 
however,  the  protocol  is  not  P-protective  even  if  B  behaves  as  trusted.  In  fact,  P-protection  is 
not  compromised  by  P’s  deviations  in  this  case.  It  is  compromised  by  P’s  deceptions  earlier  in  the 
withdrawal  protocol,  when  the  coin  was  withdrawn. 


5.9  Conclusion 

Of  our  three  case  studies,  Brands’s  protocol  is  the  most  challenging.  It  is  challenging  because 
there  has  been  no  previous  studies  of  ecash  protocols  with  respect  to  fairness  or  protection  of 
individuals’  interests,  and  we  had  to  devise  our  own  approach  to  tackle  this  problem.  For  example, 
since  protection  of  individuals’  interests  is  a  transaction-related  concept,  and  Brands’s  protocol 
implements  different  types  of  transactions,  we  do  not  analyze  the  protocol  as  a  monolithic  unit. 
Instead,  we  focus  on  each  of  the  different  types  of  transactions,  and  analyze  each  of  the  subprotocols 
separately.  Also,  we  had  to  propose  protection  properties  for  these  subprotocols  afresh. 

Dividing  up  the  protocol  for  analysis  does  not  make  the  subsequent  analysis  effort  and  its 
results  trivial  or  insignificant:  the  results  we  obtained  and  the  insights  we  gained  prove  it.  Besides 
standing  on  their  own  as  protection  results,  the  outcomes  of  these  analyses  provide  insights  as 
to  whether  or  not  the  protocol  satisfies  certain  other  properties.  For  example,  violation  of  P’s 
interests  in  the  payment  protocol  allows  us  to  conclude  immediately  that  Brands’s  protocol  is 
not  money-atomic  [84].  We  suspect  that  treating  ecash  subprotocols  separately  may  be  a  feasible 
divide-and-conquer  approach  to  master  the  complexity  of  defining  protocol-wide  properties,  e.g., 
money  atomicity,  and  analyzing  protocols  with  respect  to  these  properties. 

As  for  the  protection  properties  we  proposed  for  the  three  subprotocols,  we  do  not  claim  that 
they  are  absolute,  but  we  believe  that  they  capture  the  essence  of  what  different  parties  see  as 
their  interests,  and  when  these  interests  are  protected.  More  than  trying  to  establish  a  set  of 
absolute  protection  properties  for  ecash  protocols,  we  aimed  to  show  that  the  notion  of  protection 
is  applicable  to  more  than  just  exchange  protocols. 

Of  all  the  problems  detected  by  our  analysis,  no  one  is  more  subtle  than  the  violation  of  P’s 
protection  property  in  the  deposit  protocol.  It  is  so  subtle  that  our  analysis  is  the  first  to  reveal  it 
since  Brands’s  protocol  [14]  was  first  published.  We  attribute  our  success  in  revealing  it  to  the  use 
of  our  analysis  framework. 

The  two  trust  assumptions  we  identified  for  B  are  not  surprises.  In  withdrawal  transactions,  B 
is  expected  to  generate  signatures  ( Tbw )  correctly,  while  in  deposit  transactions  B  is  expected  to 
deposit  coins  that  are  worth  money  (TbJ. 
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The  trust  assumptions  we  identified  for  O  are  somewhat  unexpected.  Used  to  restrain  double¬ 
spending,  it  would  seem  more  intuitive  if  the  trust  placed  on  O  was  about  not  enabling  multiple 
spendings.  However,  since  the  protocol  has  a.  safety  net  to  handle  potential  failures  of  the  restraining 
mechanism,  no  trusted  behavior  is  required  of  O  in  this  respect.  In  contrast,  P  depends  critically 
on  O  to  generate  a  spendable  coin  and  then  to  spend  it.  Thus,  the  trust  assumed  of  O  concerns  O' s 
generating  its  contribution  to  the  substrates  ( Tow )  properly,  and  O' s  providing  the  protocertificates 
(Top)  properly.  Violation  of  either  Tow  or  Top  will  make  a  coin  non-spendable,  and  P  would  lose 
money. 

Finally,  note  that  all-protection  is  not  complete  security.  Even  if  all  subprotocols  of  an  ecash 
protocol  were  all-protective,  the  entire  protocol  may  still  be  insecure.  For  example,  none  of  our 
protection  properties  addresses  whether  payers  are  eventually  able  to  spend  spendable  coins  they 
own;  a  protocol  is  clearly  insecure  if  it  fails  to  guarantee  that  one  can  eventually  spend  a  spendable 
coin  that  one  withdraws. 

5.10  Feedback  from  Stefan  Brands 

In  this  section,  we  report  on  Brands’s  comments  on  our  analysis  [17]. 

First,  there  seems  to  be  different  notions  of  what  lies  within  the  scope  of  a  cryptographic 
protocol  design.  For  Brands  [17],  fault-tolerance  and  the  like  are  not  core  issues  that  should  be 
addressed  within  the  design  of  a  cryptographic  protocol.  Because  of  this  view,  he  argues  that 
some  of  the  weaknesses  we  point  out  are  not  weaknesses  of  the  cryptographic  protocol;  instead, 
they  relate  to  fault-tolerance.  Violations  of  P-protection  in  both  the  withdrawal  protocol  and  the 
payment  protocol  due  to  channel  failures  (entries  (1)  in  Table  5.1  (p.  127)  and  Table  5.2  (p.  135)) 
fall  into  this  category.  Fault-tolerance  measures  needed  to  address  these  violations  are  discussed 
by  Brands  himself  elsewhere  [15]. 

Other  violations  of  P-protection  in  the  payment  protocol  (entries  (2)  and  (3)  in  Table  5.2 
(p.  135))  are  due  to  P’s  abortion  and  deception.  A  return  protocol  [16]  that  allows  P  to  return  the 
affected  coin  is  needed  in  these  cases. 

Finally,  protection  of  P’s  interests  in  the  deposit  protocol  (entries  (1)  in  Table. 5. 3  (p.  143))  can 
be  guaranteed  if  B  always  deposits  valid  coins  that  are  accompanied  by  fresh  rights  certificates  [15]. 
Under  this  mode  of  operation,  problem  coins  that  were  rejected  for  deposit  are  now  accepted,  and 
P-protection  is  restored. 
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Chapter  6 


Conclusions  and  Future 


Work 


The  general  goal  of  this  research  is  to  answer  questions  such  as:  What  do  electronic  commerce 
protocols  try  to  achieve?  What  must  they  achieve?  And  how  do  they  achieve  it?  My  thesis  in 
this  dissertation  is  that  1)  in  electronic  commerce  transactions  where  participants  have  different 
interests  to  preserve,  protection  of  individuals’  interests  is  a  concern  of  the  participants,  and  should 
be  guaranteed  by  the  protocols;  and  2)  a  protocol  should  protect  a  participant’s  interests  whenever 
the  participant  behaves  according  to  the  protocol  and  trusted  parties  behave  as  trusted. 

To  make  this  thesis  precise,  we  formulated  a  model  for  electronic  commerce  systems  and  gave 
a  definition  of  protection  of  individuals’  interests  in  this  model.  To  demonstrate  the  applicability 
of  our  model  and  to  investigate  how  well  electronic  commerce  protocols  do  with  respect  to  this 
requirement,  we  analyzed  three  protocols  using  our  framework. 

In  the  rest  of  this  chapter,  we  first  summarize  and  reflect  on  the  results  (Section  6.1).  We  then 
discuss  future  work  (Section  6.2).  Finally,  we  provide  a  few  remarks  on  formal  methods  research 
as  applied  to  electronic  commerce  protocols  (Section  6.3). 


6.1  Summary  and  Reflections  of  Results 

We  discuss  our  framework  and  the  case  studies  in  turn. 

6.1.1  The  Framework 

Our  framework  for  analyzing  protocols  with  respect  to  protection  of  individuals’  interests  is  model- 
theoretic.  It  consists  of  a  protocol  specification  formalism,  a  model  of  electronic  commerce  systems, 
and  a  definition  of  ^protective  protocols  (where  p  is  a  protocol  participant).  Our  protocol  specifi¬ 
cation  formalism  is  a  standard  rule-based  formalism  in  which  one  can  specify  trust  assumptions  of 
a  protocol  in  linear-time  temporal  logic.  Our  model  consists  of  standard  state  machines  with  which 
we  can  distinguish  some  particular  types  of  protocol  executions:  compliant,  abortive,  deceptive, 
and  trustworthy.  Finally,  our  definition  of  p-protective  protocols  establishes  the  set  of  executions 
one  should  consider  in  order  to  conclude  whether  a  protocol  protects  the  interests  of  a  participant  p. 

Using  our  framework,  one  can  examine  a  protocol  under  three  deviation  modes:  1)  compliance 
mode,  where  the  participants  execute  according  to  the  protocol;  2)  abortion  mode,  where  they  can 
terminate  their  executions  prematurely;  and  3)  deception  mode,  where  they  can  send  bogus  mes¬ 
sages.  Trusted  parties  can  deviate  as  well,  but  they  do  not  violate  a  protocol’s  trust  assumptions. 
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That  is,  their  executions  are  always  trustworthy.  Under  each  deviation  mode,  one  can  consider 
both  reliable  and  unreliable  communication  links.  These  deviation  modes  do  not  cover  all  possible 
deviations,  but  they  model  attacks  that  do  not  require  many  resources  or  much  sophistication, 
which  constitute  most  of  the  attacks  on  electronic  commerce  protocols  [1], 

This  framework  is  useful  because  it  builds  on  well-known  and  simple  models  and  formalisms 
and  enables  investigation  of  an  assortment  of  electronic  commerce  protocols  with  respect  to  a  novel 
and  critical  property. 

Also,  since  protection  of  individual  interests  is  a  very  general  notion  and  we  do  not  specify 
what  exactly  can  be  protection  properties,  our  framework  is  potentially  widely  applicable.  For 
example,  it  seems  to  be  readily  applicable  to  formalize  and  analyze  protocols  with  respect  to 
abuse-freeness  [43],  a  property  recently  introduced  for  contract  signing  protocols.  A  contract  signing 
protocol  is  abuse-free  if  no  party  can  ever  prove  to  a  third  party  that  he  or  she  is  capable  of  choosing 
whether  to  validate  or  invalidate  a  contract.  Abuse-freeness  is  clearly  an  instance  of  protection  of 
individuals’  interests,  and  to  analyze  a  protocol  with  respect  to  this  property,  one  simply  needs  to 
specify  the  corresponding  protection  properties  in  temporal  logic.  Abstractly,  protection  properties 
corresponding  to  abuse-freeness  have  the  following  general  pattern: 

Let  p  and  q  be  parties  signing  a  contract.  If  p  signs  the  contract  at  a  state  s,  then  there 
cannot  be  a  state  in  the  future  in  which  q  can  prove  that  she  can  either  validate  the 
contract  or  invalidate  it. 

6.1.2  The  Case  Studies 

We  analyzed  three  protocols  using  our  framework. 

Franklin  and  Reiter’s  Protocol 

This  protocol  is  the  simplest  among  the  three  we  analyzed,  in  terms  of  both  its  functionality  and 
its  protection  properties.  Our  analysis  did  not  reveal  any  surprises:  the  protocol  is  all-protective 
under  all  three  deviation  modes,  as  long  as  communication  links  are  reliable. 

Our  main  contributions  in  this  case  study  is  a  formalization  of  semi-trusted  third  parties. 
Franklin  and  Reiter  introduced  the  notion  of  semi-trustworthiness  in  electronic  commerce  proto¬ 
cols  [42],  but  they  did  not  fully  develop  it.  In  particular,  they  did  not  take  it  into  account  in 
their  (informal)  analysis  of  the  protocol.  Using  our  framework,  we  could  formalize  the  notions  of 
semi-trustworthiness  and  conspiracy  behaviors,  and  provide  a  clear-cut  analysis  of  the  protocol. 

NetBill 

This  protocol  is  the  second  in  complexity  (among  the  three  we  analyzed),  but  its  protection  prop¬ 
erties  are  the  most  complex.  The  complexity  stems  from  the  fact  that  NetBill  is  a  protocol  that 
supports  dispute  resolution,  and  its  protection  properties  need  to  take  into  account  not  only  on-line 
exchanges  of  money  and  goods,  but  also  how  disputes  are  resolved. 

In  terms  of  protection  of  individuals’  interests,  our  analysis  did  not  reveal  any  surprises.  NetBill 
is  both  customer-protective  and  merchant-protective  under  all  three  deviation  modes,  even  when 
communication  links  can  fail.  NetBill  is  not  affected  by  link  failures  because  the  NetBill  server  is 
assumed  to  be  permanently  reachable. 
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Our  analysis,  however,  did  make  explicit  interesting  points  about  how  the  protocol  guarantees 
all-protection,  and  what  the  NetBill  server  is  trusted  to  do.  Under  compliance  and  abortion  modes, 
all-protection  is  guaranteed  by  the  server’s  transaction  capabilities  alone;  certified  delivery  is  needed 
only  under  deception  mode.  More  interestingly,  certified  delivery  achieves  its  goals  only  if  the 
NetBill  server  satisfies  a  small  set  of  trust  assumptions.  Basically,  the  server  is  entrusted  to  handle 
accounts  and  keys  honestly;  to  provide  unique  and  non-repudiable  proofs  of  what  happens  on-line 
through  transaction  slips;  and  to  allow  merchants  to  learn  what  really  happens  with  a  transaction 
-  so  that  keys  are  not  given  to  customers  without  their  knowledge.  Even  though  it  may  seem 
counter-intuitive  at  first,  NetBill’s  all-protection  does  not  depend  on  the  server’s  releasing  the  keys 
sent  to  it  by  merchants,  or  its  retaining  transaction  requests. 

Brands’s  Protocol 

This  case  study  is  the  most  interesting  for  three  reasons.  First,  we  had  to  derive  an  abstract  version 
of  the  protocol  from  its  purely  mathematical  formulation  [14].  This  exercise  is  challenging  because 
the  protocol  is  very  complex  (not  only  compared  to  the  other  two  protocols,  but  in  absolute  terms), 
and  it  is  not  immediately  clear  how  abstract  we  should  model  the  protocol. 

Second,  to  our  knowledge,  there  has  not  been  analysis  of  ecash  protocols  with  respect  to  pro¬ 
tection  of  individuals’  interests.  This  means  that  there  is  no  standard  protection  properties  for 
these  protocols,  and  we  had  to  propose  them  afresh.  The  properties  we  proposed  might  not  be 
definitive,  but  we  believe  that  they  capture  the  essence  of  what  different  parties  see  as  their  inter¬ 
ests.  More  than  trying  to  establish  a  set  of  absolute  protection  properties  for  ecash  protocols,  we 
aimed  to  show  that  parties  in  such  protocols  do  have  different  interests  to  preserve,  and  the  notion 
of  protection  of  individuals’  interests  is,  in  fact,  applicable  to  more  than  just  exchange  protocols. 

Finally,  our  analysis  revealed  a  number  of  weaknesses  in  the  protocol.  Some  of  the  weaknesses 
are  well-known  and  far  from  subtle;  for  example,  that  ecoins  can  get  lost  during  transmission. 
Others,  however,  are  quite  subtle,  and  have  not  been  found  before.  For  example,  a  payee  can  either 
abort  or  deceive,  and  effectively  make  the  payer’s  money  disappear,  even  if  communication  links 
are  reliable.  Also,  withdrawers  can  deceive,  and  withdraw  perfectly  valid  coins  that  they  can  spend, 
but  will  be  neither  accepted  for  deposit,  nor  usable  for  tracing  the  identity  of  the  withdrawer. 

Brands  does  not  make  clear  his  assumptions  about  how  different  parties  can  misbehave,  and 
arguably  did  not  design  the  protocol  to  counteract  the  attacks  we  found.  In  any  case,  these  attacks 
are  realistic,  pose  real  threats  to  the  users,  and  should  be  taken  into  account. 

We  were  able  to  unveil  these  weaknesses  because  we  have  a  well-defined  deviation  model  in  which 
protocols  can  be  systematically  analyzed.  This  testifies  to  the  importance  of  systematization  and 
formalization  that  go  into  formulating  frameworks  such  as  ours. 

Our  analysis  gave  us  other  interesting  insights.  For  example,  it  showed  how  vulnerable  payers 
become  when  observers  are  corrupted.  While  there  is  a  whole  mechanism  for  tracing  double- 
spenders  should  an  observer  fail  to  prevent  double-spending,  there  is  no  recourse  for  the  payer  to 
recover  her  money,  if  the  observer  fails  to  authorize  a  rightful  spending  of  a  valid  coin. 

The  discussion  above  is  based  on  our  analysis  of  Brands’s  protocol  as  it  was  presented  in  his 
Crypto  ’93  paper  [14].  According  to  our  recent  personal  communication  with  Brands  [17],  that 
paper  presents  only  the  core  cryptographic  protocol;  it  does  not  include  fault  tolerance/recovery 
measures  discussed  in  Section  5.10,  which  Brands  considers  outside  the  scope  of  protocol  designs. 

Even  though  the  protocol  we  analyzed  is  incomplete  and  the  weaknesses  we  found  are  not  present 
in  the  complete  protocol,  our  analysis  is  still  valuable.  It  shows  that  protection  of  individuals’ 
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interests  indeed  captures  a.  notion  of  security  that  should  be  guaranteed  by  electronic  cash  protocols. 
It  also  shows  that  our  framework  can  be  effectively  used  to  find  problems  related  to  this  type  of 
security  in  protocols. 

6.2  Future  Work 

There  are  several  directions  along  which  we  can  further  develop  this  research.  The  main  ones  are 
discussed  below. 

Analysis  Automation 

The  most  pressing  future  work  is  automation.  We  analyzed  all  three  protocols  by  hand,  and  the 
process  is  tedious  and  slow.  An  automatic  (or  semi-automatic)  analyzer  would  greatly  improve 
the  efficiency  of  the  analysis  process,  in  addition  to  minimizing  proof  errors  that  are  common  in 
manual  analyses. 

It  is  possible  to  model  our  framework  in  existing  general-purpose  tools.  Schneider’s  analysis  [78] 
of  Zhou  and  Gollman’s  non-repudiation  protocol  [89]  using  CSP  [52]  is  an  indication  that  our 
analyses  can  be  carried  out,  in  principle,  in  FDR  [64].  However,  since  FDR  is  a  trace-based  model 
checker,  mapping  what  we  have  developed  to  FDR  is  not  straightforward.  A  state-based  model 
checker  that  uses  temporal  logic  as  specification  language  would  require  less  effort. 

Model  checkers  give  us  a  greater  degree  of  automation,  but  theorem  provers  allow/force  us  to 
be  more  explicit  and  precise  in  our  models  and  specifications.  Since  our  framework  emphasizes 
explicitly  making  assumptions  that  usually  remain  implicit,  automation  based  on  theorem  proving 
is  preferable  for  our  purposes. 

Alternatively,  we  can  build  a  special-purpose  tool,  custom-built  for  investigating  protection  of 
individuals’  interests.  A  good  argument  for  building  such  a  tool  is  that  it  will  incorporate  our 
model  and  definition,  and,  in  the  case  of  model  checkers,  automatically  generate  different  sets  of 
executions  that  need  to  be  considered. 

Further  Exploration  Using  Our  Framework 

A  different  direction  for  future  work  is  to  use  the  framework  that  we  now  have  in  place  to  explore 
further  the  issue  of  protection  of  individuals’  interests  in  electronic  commerce  protocols.  One 
possibility  is  to  investigate  classes  of  protocols  that  we  have  not  looked  at.  Voting  and  auction 
protocols  are  types  of  protocols  we  would  investigate  next. 

Another  possibility  is  to  deepen  the  analyses  we  have  done,  possibly  by  strengthening  or  adding 
to  current  protection  properties.  For  example,  does  the  server  in  NetBill  have  interests  to  preserve 
in  a  transaction?  If  yes,  what  are  these  interests?  We  suspect  that,  as  a  service  provider,  the 
NetBill  server  may  or  may  not  have  monetary  or  material  interests  in  transactions;  however,  it 
certainly  has  its  reputation  to  preserve.  In  the  case  of  ecash  protocols,  are  there  other  interests 
that  payers  may  want  to  preserve  in  addition  to  preserving  the  value  of  their  coins?  Protection  of 
privacy,  which  we  did  not  address  in  this  dissertation,  is  something  that  payers  certainly  care  about. 
But  is  privacy  a  different  type  of  property  altogether?  Or  is  it  simply  a  subtype  of  individuals’ 
interest?  These  questions  are  worth  investigating. 
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Enriching  the  Framework 

The  framework  itself  can  be  further  extended.  One  obvious  extension  is  to  add  other  deviation 
modes.  For  example,  we  can  add  a  more  permissive  type  of  deception. 

The  type  of  deception  we  defined  in  this  dissertation  (Definition  2.16)  is  stringent  in  that  a 
deceptive  step  does  not  violate  the  conditions  for  the  firing  of  the  protocol  rule.  These  conditions 
typically  include  two  components:  1)  a  specification  of  protocol  steps  that  should  or  should  not 
have  taken  place,  and  2)  a  specification  of  conditions  that  these  previous  steps  must  satisfy.  In  rule 
RZi  in  Franklin  and  Reiter’s  protocol  (page  37),  for  example,  everything  except  line  3  falls  into  the 
first  component,  while  line  3  itself  falls  into  the  second. 

A  more  permissive  type  of  deception  would  allow  the  initial  state  of  a  state  transition  to  violate 
the  second  component,  for  instance.  This  new  type  of  deception  models  the  cases  where  a  principal 
takes  steps  in  the  order  prescribed  by  the  protocol,  without  checking  whether  he  or  she  should 
actually  take  the  steps.  A  concrete  example  is  when  Z  in  Franklin  and  Reiter’s  protocol  fires  the 
rule  Rz4  and  forwards  a  message  to  X  even  if  the  secret  sharings  between  X  and  Z,  and  Y  and  Z 
(as  specified  in  line  3  in  Rz4)  cannot  be  verified. 

The  notion  of  trust  assumptions  itself  requires  better  understanding.  For  example,  given  a 
protocol  and  a  protection  property,  is  there  a  unique  set  of  trust  assumptions  that  would  allow 
the  protocol  to  guarantee  the  property?  If  not,  how  can  we  compare  two  different  sets  of  trust 
assumptions?  Ideally,  the  weaker  the  trust  assumptions  of  a  protocol,  the  less  vulnerable  it  is,  and 
possibly  the  cheaper  it  is  to  build. 

Also,  the  types  of  trust  assumptions  required  by  a  protocol  depend  on  under  which  deviation 
modes  the  protocol  is  supposed  to  function.  The  set  of  trust  assumptions  we  devised  in  our  case 
studies  addressed  abortive  and  deceptive  deviations.  As  we  add  other  deviation  modes  to  our 
model,  we  will  also  need  to  add  additional  trust  assumptions.  Will  these  additional  assumptions 
be  formalizable  in  temporal  logic?  Or  will  we  need  a  different  formalism? 

Currently,  our  model  handles  only  finite  executions.  Not  all  protocols  have  finite  executions, 
however.  For  example,  there  can  be  servers  that  can  respond  to  requests  infinitely  often.  We  can 
extend  our  model  to  handle  these  cases.  For  example,  we  can  consider  both  maximal  executions  and 
infinite  executions,  and  require  that  infinite  executions  have  finite  prefixes  that  satisfy  appropriate 
protection  properties.  (The  requirements  on  maximal  executions  remains  the  same.) 

Relationship  to  Other  Properties 

Identifying  a  new  property  is  important.  Just  as  important  is  establishing  the  relationship  between 
a  new  property  and  the  existing  ones.  In  this  dissertation,  we  have  established  the  relationship 
between  fairness  and  protection  of  individuals’  interests.  There  are  others  to  be  explored.  For 
example,  what  is  the  relationship  between  protection  of  individuals’  interests  in  ecash  protocols 
and  money-atomicity  [84]?  In  Brands’s  protocol,  violation  of  payer’s  interests  allows  us  to  conclude 
immediately  that  the  protocol  is  not  money-atomic.  But  can  money-atomicity  be  defined  in  terms 
of  protection  of  individuals’  interests  and  other  more  “primitive”  properties?  If  so,  then  we  will  be 
taking  a  step  towards  understanding  these  more  complex,  protocol-wide  properties. 

Finally,  we  can  try  to  identify  other  classes  of  properties  that  are  relevant  to  electronic  commerce 
protocols. 


6.3  Closing  Remarks 

In  this  dissertation,  we  identified  protection  of  individuals’  interests  as  a  critical  requirement  for 
electronic  commerce  protocols  where  participants  have  different  interests  to  preserve.  We  then 
formulated  a  model-theoretic  framework  in  which  protocols  can  be  analyzed  with  respect  to  this 
requirement. 

Two  related  factors  make  this  work  a  significant  step  forward  towards  understanding  electronic 
commerce  protocols.  First,  it  has  extracted  the  essence  of  a  property  that  is  expected  in  a  diverse  -» 

range  of  electronic  commerce  protocols.  Second,  because  the  framework  captures  only  what  is 
essential,  it  is  in  turn  applicable  to  a  wide  range  of  electronic  commerce  protocols.  This  generality 
is  highly  desirable  because  it  will  save  us  from  rediscovering  what  others  have  discovered  in  similar 
contexts.  For  instance,  a  number  of  challenges  faced  by  Shmatikov  and  Mitchell  [80]  in  analyzing 
a  contract  signing  protocol  were  faced  by  Heintze  et  al  [51]  in  analyzing  a  payment  protocol  and 
an  ecash  protocol.  These  same  challenges  were  also  encountered  by  Schneider  [78]  in  analyzing  a 
non-repudiation  protocol.  Now,  they  can  all  be  handled  in  our  framework. 

Our  framework  is  appealing  because  it  uses  well-known  and  simple  models  and  formalisms. 

Thus,  it  can  be  readily  applied  as  is,  or  be  mapped  into  one’s  favorite  formalism. 

Despite  its  simplicity,  our  framework  can  handle  complex  protocols,  as  is  demonstrated  by  our 
analysis  results.  The  framework  provides  not  only  the  low-level  apparatus  for  formalization  and 
analysis,  but  also  a  high-level  frame  of  reference  for  protocol  design. 

Finally,  protection  of  individuals’  interests  is  just  one  of  the  properties  of  interest  in  electronic 
commerce  protocols.  Many  others  still  await  our  investigation. 
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